2007.03.06 Roundtable Summary
Gregory Brown
which was more than 2.5 hours long, without making this email equally
lengthy. Please use this as an opportunity to continue discussions
started at the meeting, whether or not you attended. If you do want
to discuss a particular topic, please change the subject line on your
reply to reflect this. Looking forward to hearing some thoughts on
these things!
-greg
----------------------------
= Ruby Reports IRC Roundtable : 2007.03.06 =
== Participants ==
- Gregory Brown <sandal>
- Dudley Flanders <dudleyf>
- Michael Milner <mikem836>
- Dinko Mehinovic <Dinko>
- Chris Carter <cdcarter>
- Zed Shaw <zedas>
- Brian DeLacey <bdelacey>
- Aredridel <Aria>
- Shout if I missed you
+ several lurkers.
== Transcript ==
If you missed it yesterday or want to refer to it, you can find the
transcript at:
http://rubyreports.org/transcripts/roundtable-2007.03.06.txt
Which is also linked to from our ChatLogs section of the wiki (for bookmarking)
http://stonecode.svnrepository.com/ruport/trac.cgi/wiki/ChatLogs
== Introduction ==
I mostly reminded people of the release cycle and development process
changes I announced a couple weeks ago on the list.
This basically consisted of reminding people that the last official
stable release branch before 1.0 will be the 0.8.x branch, but that
everyone is encouraged to begin using 0.9 as soon as it is released,
to help us test it out as well as to provide feedback for the system
that will eventually become Ruport 1.0
Major difference between 0.8 and 0.9:
- 0.9 will be on gems.rubyreports.org only
- 0.9 is *developmental*, behaviour might change with each release.
- 0.8 will not change behaviour, except by plugins which support 0.8
If you haven't read the article about this yet, you may wish to do so now:
http://blog.rubyreports.org/archives/33
== 0.9 versioning ==
I suggested possibly going to a 4 version scheme for 0.9, so that we
could express maintainence vs. behaviour changes.
i.e.
0.9.0.1 -> 0.9.0.2 # bug fix
0.9.0.2 -> 0.9.1.0 # behavior change
This idea didn't seem to attract much interest, so I think we're going
to be a little looser with it.
- All version of 0.9 might change behaviour, so keep an eye on release notes
- We're reserving 0.9.97 or so on up for 1.0 release candidates
== Milestones for 0.9 ==
You can see this in Trac, it's what's left to be done before we can release 0.9
It's substantially shorter now: http://tinyurl.com/2rb2jr
Projected release date: March 10th.
== Documentation Issues ==
We've agreed again that James Healy's Formatting System Tutorial rocks:
http://www.yob.id.au/articles/ruport_formatting_system.html
The problem is, that it (like all other documentation aside from the
API), is written against 0.7
I've been referring to Ruport 0.7 as "the 1980s" pejoratively. So
we'll need to get it up to date so it can continue to remind us how to
use Ruport's formatting system.
Aria made a great point about this... what Ruport needs right now is
some more step by step, comprehensive tutorials which cover the big
picture and some concepts behind Ruport.
We talked quite a bit about this last night, enough to get Mike and I
talking this afternoon about trying to solve this problem. Expect an
announcement soon.
== Gem Plugin FUD ==
Aria and Chris brought up concerns that gem_plugin magic is scary.
It's true there is some possible issues with trying to autoload all
the plugins at once.
We've identified a couple, and we've made it so you have to explicitly
require "ruport/extensions" to enable gem_plugin support. Zed is also
going to work on resolving an issue with gem locking, which will
eliminate some concerns.
The real draw I have to gem_plugin is it took me about 30 minutes to
integrate it. If someone could come up with a better system for
Ruport, I'm not opposed to considering using it, but that would
preferably be done before 1.0
I'm going to investigate how easy it would be to make the plugins I've
created usable with or without gem_plugin. If it's a sane procedure,
I'll share recommendations with others to help those who'd prefer to
do things more manually.
== Is Trunk Stable Enough For Use? ==
Chris asked us this, and since it varies from project to project, it's
definitely worth mentioning.
I don't want to make promises about this, since in all honesty it
depends on the revision ;)
However, here are some things to note:
- We develop almost entirely test driven
- Most of the core team and major contributors run from svn builds
- We respond to bug reports very quickly
- We have a 'don't break the build' policy
If you do wish to run trunk, the important thing to keep in mind is to
copy the RSS feed or keep an eye on our Trac timeline. This will keep
you aware of changes.
http://stonecode.svnrepository.com/ruport/trac.cgi/timeline
Also, you may wish to record revision numbers and freeze to specific
revisions if you're building an app against trunk.
== New Formatting System Features ==
There is some major overhaul going on in the 0.9 formatting system.
I'll actually post some more details about this soon enough, but most
of the stuff we talked about has trickled across the list in parts.
Some new stuff:
* Multi-purpose plugins
* Lots of hooks in the renderer for doing setup and autorunning
* Integration with Report via Report#renders_with
* New PDF helpers
* Work on Grouping format support
* Row based Renderers
== acts_as_reportable views ==
Mike is going to work a bit more on this, but he's still looking for feedback.
See this thread for details:
http://groups.google.com/group/ruby-reports/browse_thread/thread/279776379e8cbda8
== Continuous Integration ==
We might consider using Cerberus, but with only 5 committers and only
two of us being regularly active (me and Mike), it might be a solution
in search of a problem. I suppose if more people are planning on
using svn builds of Ruport, this might be more important. Let us
know.
== Dedicated Hosting / VPS ==
This topic has been thrown around before. We've made life a little
easier by cutting down on the number of ISPs we're working with and
linking everything at least through redirects all at rubyreports.org
People have offered to share a VPS with us, but what we'd really need
is for someone to literally give us a blank box to work with in order
to consolidate all our resources. We know this is expensive, and
that's why we aren't soliciting for it. However, if you happen to
work at an ISP and can hand these things out like candy, or you happen
to be sitting on a pile of money you want to hand over with no
restrictions to the Ruport developers, contact us. :)
== The bad example ==
Chris carter hates [[1,2,3],[4,5,6]].to_table(%w[a b c])
Perhaps I can write a better vim macro to give you guys prettier (more
realistic) examples. :)
== tapply / pivots for data manipulation ==
Zed Shaw suggested that we might want to implement pivot tables and/or
the tapply function.
I gave pivots a hard look just before 0.8 and they seemed a bit tricky
to implement efficiently.
tapply() shows serious potential and could be really powerful for some
basic manipulations.
There is a good chance I'll get to work on this in the next couple
weeks, but a patch for pivot tables and/or tapply() would certainly be
welcome!
For details on tapply: http://pbil.univ-lyon1.fr/library/base/html/tapply.html
== webgen looks interesting ==
We might use this for rubyreports.org, but we have different plans for
the articles idea in the short term, which I'll announce later.
====== That's All.
So it did end up being quite long. Hopefully the headings made it
skip friendly.
Looking forward to any continued discussions as we keep things rolling
towards 1.0
James Healy
> == Is Trunk Stable Enough For Use? ==
>
> Chris asked us this, and since it varies from project to project, it's
> definitely worth mentioning.
Don't forget API stability as well (as opposed to lack of bugs, etc).
The API has been changing rapidly which may have made things difficult
to learn, let alone integrate with a production app safely.
Hopefully things will settle down from 1.0. Which is possibly how it
should be - all these crazy open source apps / libs that never hit 1.0
can get annoying.
-- James Healy <ji...@deefa.com> Thu, 8 Mar 2007 16:29:07 +1100
Gregory Brown
> Gregory Brown wrote:
> > == Is Trunk Stable Enough For Use? ==
> >
> > Chris asked us this, and since it varies from project to project, it's
> > definitely worth mentioning.
>
> Don't forget API stability as well (as opposed to lack of bugs, etc).
Ah yes. There will be no API stability in trunk per say, but the big
goal is to stabilize the API to be consistent for 1.0
So I guess that means, don't hit up 0.9 for the next few weeks if you
want to avoid this, but if you want to help shape things, please do.
We plan to cool off the API as soon as feature completeness has been
reached. (And at least for my needs, we're edging pretty close to
that)
> The API has been changing rapidly which may have made things difficult
> to learn, let alone integrate with a production app safely.
For this reason, we plan to support 0.8 until 1.0 is ready, but in
terms of documentation beyond the API docs, it will be up to users to
contribute tutorials and whatnot, unless you (or anyone else really)
are volunteering to actively support the stable branch James. ;)
> Hopefully things will settle down from 1.0. Which is possibly how it
> should be - all these crazy open source apps / libs that never hit 1.0
> can get annoying.
Yes, 1.0 will come. Hopefully by mid May at the latest.