[Koha-devel] rel_2_0 CVS branch

[paul POULAIN]

Pat Eyler a écrit :

>On Wed, 17 Dec 2003, MJ Ray wrote:
>  
>
>>On 2003-12-16 23:53:22 +0000 Pat Eyler <pate at 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)