Hi All I have branched the koha cvs tree. The new branch is called rel_2_0 All new features/enhancements should be done in the main trunk. All bugfixing for the 2.0 release should be done in the rel_2_0 branch. This is the new stable tree. Hence no new features should be added to it, just broken things fixed. And of course security fixes like MJ Ray is working on. This would be great to be ported back to the main tree when they are finished. Or worked on in the main tree and ported to the rel_2_0 branch. http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC52 Is a good document explaining how to work with branches cvs co -r rel_2_0 koha would check out the rel_2_0 branch. Hope this makes sense Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Thanks Chris! 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. If you're planning on doing new development work -- please hold off for a day or two. This actually brings me to a additional point. We need to think about how we're going to handle 2.0 development vs 2.2 development work. My thought is that 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. Other things (ncip, a z39.50 server, and the like) should be part of 2.2. We should try to build our list of what we want to develop in each tree, subject to the 2.0 release manager's (that'd be Paul) discretion for things going into that release. We also need to start targeting some timelines. I think we need to have a much shorter timeline for 2.2 than we did for 2.0 (for a major version change, I think we did quite well though). 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? 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've expanded this mail to include the kohabiz and koha2010 mailing lists. I think there is some good ground for those groups to cover, and hope that the discussions there will prove fruitful. thanks, -pate On Wed, 17 Dec 2003, Chris Cormack wrote:
Hi All
I have branched the koha cvs tree. The new branch is called rel_2_0
All new features/enhancements should be done in the main trunk. All bugfixing for the 2.0 release should be done in the rel_2_0 branch. This is the new stable tree. Hence no new features should be added to it, just broken things fixed. And of course security fixes like MJ Ray is working on. This would be great to be ported back to the main tree when they are finished.
Or worked on in the main tree and ported to the rel_2_0 branch.
http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC52
Is a good document explaining how to work with branches
cvs co -r rel_2_0 koha would check out the rel_2_0 branch.
Hope this makes sense
Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
------------------------------------------------------- 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
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.
[...] 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.
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.
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'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. -- 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/
MJ Ray wrote:
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.
Not so: it's very important for libraries which are assessing or plan to assess Koha to have a good feel of how it's working "from within", so to speak. But then of course they can subscribe to the devel mailing list. Nicolas -- *********************************** Nicolas Morin Bibliotheque universitaire d'Angers 5 rue Le Notre 49045 Angers cedex - France Tél: +33 (0)2 41 22 63 11
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
Pat Eyler a écrit :
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.
yes, I agree. bugfixes are to be fixed in rel_2_0 tree by the 2.0.0 release manager and ported to the HEAD branch by the 2.2 dev team. That's how we did with 1.2 / 2.0 (& it was a huge/boring job to do it, I know what i'm speaking of...)
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.
yes. & there is a remaining question : CHRIS, when (from a CVS point of view) did you create your branch ? 2.0.0RC1 tag or 17 dec 03 cvs ? (I hope it's 2.0.0RC1 tag). In this case, who ports from HEAD to rel_2_0 bufgixes between 4 dec 03 & today ?
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 agree with this. I think we should have a 3 steps structure : 1 - stable version 2 - almost stable version 3 - probably broken version In the 3rd, we could work on "really complex features" that deals with .pm, database... In the 2nd, we could work on minor improvements (like opac recent acquisitions i've added last week) In the 1st, only bugfixes. Strictly. Something like debian "stable", "testing", "unstable".
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.
I've something to say on this... (I think i already have spoken of this with some of you, but i'm not sure). I think i will be a poor 2.0 release maintainer but a good 2.2 release manager (if you consider i've been a good 2.0 RM, of course). Why ? - I've a funder (80% sure) for serial module, the main lack of Koha for instance, so i'll be the main commiter again in head probably. - I know I'm better "inventor" than "maintainer". I think there are 3 kinds of ppl in software dev : "visionaries", "inventors", "maintainers". I'm undoubtfully NOT a maintainer. Maybe a visionnary, but for sure an "inventor". SO : - Does someone want to become 2.0.0 release manager ? - Do we have an other candidate for 2.2 RM ? (steve ?) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
paul POULAIN a écrit :
yes. & there is a remaining question : CHRIS, when (from a CVS point of view) did you create your branch ? 2.0.0RC1 tag or 17 dec 03 cvs ? (I hope it's 2.0.0RC1 tag). In this case, who ports from HEAD to rel_2_0 bufgixes between 4 dec 03 & today ?
I've found the answer : http://cvs.sourceforge.net/viewcvs.py/koha/koha/C4/Shelf.pm : Revision *1.4* - (download) <http://cvs.sourceforge.net/viewcvs.py/*checkout*/koha/koha/C4/Shelf.pm?rev=1.4>, view (text) <http://cvs.sourceforge.net/viewcvs.py/*checkout*/koha/koha/C4/Shelf.pm?content-type=text%2Fplain&rev=1.4> (markup) <http://cvs.sourceforge.net/viewcvs.py/koha/koha/C4/Shelf.pm?rev=1.4&view=markup> (annotate) <http://cvs.sourceforge.net/viewcvs.py/koha/koha/C4/Shelf.pm?annotate=1.4> - [select for diffs] <http://cvs.sourceforge.net/viewcvs.py/koha/koha/C4/Shelf.pm?r1=1.4> /Mon Dec 15 13:41:43 2003 UTC/ (3 days, 1 hour ago) by /slef/ CVS Tags: *HEAD* <http://cvs.sourceforge.net/viewcvs.py/koha/koha/C4/Shelf.pm?only_with_tag=HEAD> Branch point for: *rel_2_0* <http://cvs.sourceforge.net/viewcvs.py/koha/koha/C4/Shelf.pm?only_with_tag=rel_2_0> Changes since *1.3: +9 -9 lines* Diff to previous 1.3 <http://cvs.sourceforge.net/viewcvs.py/koha/koha/C4/Shelf.pm?r1=1.3&r2=1.4> DBI call fix for bug 662 The branch has been created yesterday in CVS. No backport / foreport needed for instance. So : Slef & all : please commit BUGFIXES in REL_1_2, and the 2.2 release manager will foreport them in HEAD. I'll act as "foreporter" until official 2.2 release manager is elected/nominated. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 2003-12-18 15:09:11 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
So : Slef & all : please commit BUGFIXES in REL_1_2, and the 2.2 release manager will foreport them in HEAD.
REL_1_2?
I'll act as "foreporter" until official 2.2 release manager is elected/nominated.
Who's taking care of releasing 2.0 if you're going off to do 2.2? -- 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/
MJ Ray a écrit :
On 2003-12-18 15:09:11 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
So : Slef & all : please commit BUGFIXES in REL_1_2, and the 2.2 release manager will foreport them in HEAD.
REL_1_2?
sorry, typo error : REL_2_0, of course.
I'll act as "foreporter" until official 2.2 release manager is elected/nominated. Who's taking care of releasing 2.0 if you're going off to do 2.2?
I won't stop anything Slef : * i say i'm a candidate to become RM 2.2, but only if a 2.0 maintainer is nominated. * i say i'll foreport 2.0 bugfixes to head branch until someone else is nominated. * i continue working on 2.0 until things are clear. Is it clear now ? do you want to be candidate for 2.x manager/maintainer ? -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 2003-12-18 14:57:52 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
I think we should have a 3 steps structure : 1 - stable version 2 - almost stable version 3 - probably broken version
I think this is too much. I think it strains us to support two branches, let alone three. Have a stable series and one open for development and let people do radical restructuring attempts in their own space. I think Debian has 5 branches (stable, frozen, testing, unstable, experimental) as well as people using private staging areas. They're a distribution rather than a development project, so maybe not a good example. I'm leaving the RM questions alone: I don't have time right now to think about such things, thanks to bug 662. -- 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/
On 2003-12-17 17:01:33 +0000 Pat Eyler <pate@eylerfamily.org> wrote:
6 month wait for our end users to get new features is an awfully long time.
I think we've been frozen for some months now, so it'll be longer for real end users (not source builders) even if they are allowed in 2.0.
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.
Basically, we cannot expect it to stabilise while introducing new instabilities into the code. See http://www.internalmemos.com/memos/memodetails.php?memo_id=1321 for a grumble about this sort of thing about a larger software project. I'd let a new feature in if it corrects a fatal flaw, but I don't think letting simple enhancements in helps encourage the new release to come out on time. It also adds to the volume of fixes that need porting to head. I'd be happier with developers keeping 2.0 patches outside the main tree if they want a testbed/demo and trying to get them into the 2.2 tree.
I like this idea, and it's about what I was shooting for. Perhaps we should follow the gcc model.
I'm not sure we have the people yet for a full copy of this, with all the forward porting involved. I'd leave HEAD open until it's time to feature freeze. -- 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/
participants (5)
-
Chris Cormack -
MJ Ray -
nicolas morin -
Pat Eyler -
paul POULAIN