On Wed, 17 Dec 2003, MJ Ray wrote:
On 2003-12-16 23:53:22 +0000 Pat Eyler <pate@eylerfamily.org> wrote:
Please, let me second the comments below. We need to be really careful about which branch we're working in now. If you are doing bug fixes, please check out the rel_2_0 tree and do your work there.
This is the opposite of how I understood Chris's message. I have committed the last DBI fixes in C4 to HEAD and I ask Paul to backport it, please. I will now continue into the other scripts, but I'll not commit more until I know where I am supposed to be going.
As Chris said in his follow-up, the rel_2_0 tree is going to be for bug-fixes, so please commit fixes there. One place that we could really use some 'bug-fixing' is in the docs. If anyone can get involved there, Nick would certainly appreciate it. It'd probably be better if we announced the impending branch creation 24-48 hours in advance next time, and explained things then. Chris and I will try to be more clear.
[...] we've got a lot of little things that could be added into 2.0.1 (and beyond) -- things like new reports, rssKoha, and other incremental or small improvements.
New features really should go into 2.1, in my opinion, unless they are so essential as to be bugs in 2.0. The stable branch must be allowed to stabilise. The 2.2 RM should check all fixes to rel_2_0 and apply relevant ones to HEAD. That means that someone should act as 2.2 RM immediately, even if they are not going to be the real RM. http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO... gives one view on this.
There's a fine line to walk here, and I'm not sure which side I come down on. On the one hand, it's good to get new features (even the small ones) into play quickly. On the other, stablilization needs to happen. Even a 6 month wait for our end users to get new features is an awfully long time. In the 1.2 tree, we made the decision that small, safe features could be added into the stable tree without hurting things (much) and without making people wait for 2.0.0. I still tend toward this feeling, but am open to hearing reasons why it's sub-optimal. I'm going to wait to talk about a 2.2 RM for another email, as I need to let that percolate a bit longer. We do need to make sure that bug/security fixes get merged back into head regularily though. Weekly or so is probably a good target.
Ideally, I'd like to see us cutting 2.2.0 between August and October of 2004, with four or five 2.0 minor releases during that timeframe (more if we have security problems to fix). How does that sound to everyone else?
I'd set a target of 2.0.0+6 months. That probably means feature freeze at +4 or +5 months. This should make "no new features inside 2.0" rule a bit more bearable.
I like this idea, and it's about what I was shooting for. Perhaps we should follow the gcc model. 2 months of open development on HEAD, then cut rel-2-2, 2 months of rel-2-2 specific development with 2.1.X releases being made, then 2 months of rel-2-2 bug squashing, culminating in a 2.2.0 release about 6 months after 2.0.0. rel-2-4 would be cut at the same point as rel-2-2 enters the 'bug squashing' phase. We can carry this pattern forward ad infinitum. Planning on 2.0.1 at 1 month, 2.0.2 at 3 months, and 2.0.3 at 5 months would give us a good timeline for collecting, testing, and QAing bug fixes and minor new features in the stable tree while development goes on on HEAD and then rel-2-2.
During 2.2 development, I wonder if we should avoid 2.1.X releases for a while and just cut weekly snapshots until we've stabalized a bit. Does that sound reasonable? Is there a better way?
I think that's the 2.2 RM's call. Personally, I don't see much value in simple snapshots being classed as part of a release series. Might as well practice the release process or just let people use CVS. The 2.1.0 release could be a naive integration of rssKoha and similar simple features. Other features should exist outside the main 2.1 tree until they are working.
I don't really see them as part of the release series, more an early look at what's going on for people not able to or interested in tracking cvs. I think following the rolling six month outline above would handle our needs fairly well though.
I've expanded this mail to include the kohabiz and koha2010 mailing lists.
I've trimmed, as I doubt they care about the mechanics of releases and will be more concerned with features and times.
That's true for this conversation. I hope there will be some reasonable conversation around what we want to develop on those lists (and this one) though. -pate
-- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel