[Koha-devel] About Release process

Thu Jul 12 15:05:40 CEST 2012

+1  - I think Ian made a lot of good points in his mail

And I also agree with Marcel, I only think we should stop it from happening in the first place J

Katrin

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Marcel de Rooy
Sent: Thursday, July 12, 2012 1:56 PM
To: Ian Walls; koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] About Release process

Nothing to say against that, of course :)

Option 1 is/has been our goal, but what actually happened was option 2..

Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Ian Walls
Verzonden: donderdag 12 juli 2012 13:50
Aan: Fischer, Katrin
CC: koha-devel at lists.koha-community.org; Marcel de Rooy
Onderwerp: Re: [Koha-devel] About Release process

I'm mostly in favour of solution 1 (in that it's close to what I think we should to, and solution 2 is not good in my opinion).  But I think there is a little more to it.

There are several factors in our current workflow and environment that are causing these bugs and regressions:

*	Lack of robust testing suites:   All testing is done at the discretion of the sign-offer and QA team, to the best of their ability at the time.  But, any 1 person is bound to miss some aspects of even an only mildly-complex patch, either by not testing a fringe case, or not thinking of another workflow that's not common to their experience (a quote123 problem)
*	Enigmatic codebase:  Koha has grown organically for the last 12 years.  In that time, we've had not only numerous release managers and sponsoring libraries, but a significant change in the technologies underlying web services.  We are now stumbling over the anachronisms and shortcuts that have gotten us this far
*	Limited personnel:  There are only a few dozen people in the world who really, really know the Koha codebase.  These folks are the best suited to do testing and catch bugs, but they also tend to be the ones doing the development, migrations and support for libraries throughout the world.  It won't matter how clear and clean our procedures are if there aren't enough people to process them.
*	Pressure to "leave no patch behind":  we don't want to drop patches, but sometimes when a patch (particularly a large one) has gone untested or un-QAed for a long while, it's swept forward anyway in an attempt to clean out the queue.  Even if someone's code is structurally sound in and of itself, the way it interacts with the rest of the code can result in bugs.  Or, more insidiously, it introduces yet another complexity to the code that makes maintenance that much harder down the road.
*	A "we can fix it later" mentality: several large feature get pushed through the door without being completely ready to go.  The idea is that we just need to get them in, make them part of master, and then we can fix them later.  And that's exactly what we're doing.

Rather than adjusting our numbering and labeling practices, or adjusting the dates on feature freezes, I think we need to focus on resolving the above issues.  Treat the problem, not the symptoms, as it were.  It's not going to be as simple as the proposed solutions earlier in this thread, but it will lead us to a more solid, stable and extensible ILS long into the future.

Cheers,

-Ian

On Thu, Jul 12, 2012 at 6:58 AM, Fischer, Katrin <Katrin.Fischer at bsz-bw.de> wrote:

Hi all,

I agree with Chris on option 1).

We should always aim for the most stable release possible. Part of that is to add more automated tests and to get our human testing better organized.

I think releasing a beta will mean that we will end up pushing risky things to that version, because there will still be time to fix it. So it will take even longer, until we reach a stable release. Also, if something is named "beta" or "RC", I think we are unlikely to get libraries to use and test it. So it looks to me like we would be losing time and losing 2 releases that could be great.

Going into feature freeze earlier like suggested as option 1) is only about announcing too - it requires no change at all, not even a change in naming. And whenever we announce freezes - it will always be too early for some features and things we wanted to do for this next version.

Katrin

> -----Original Message-----
> From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-
> bounces at lists.koha-community.org] On Behalf Of Chris Cormack
> Sent: Thursday, July 12, 2012 12:22 PM
> To: Marcel de Rooy
> Cc: koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] About Release process
>
> * Marcel de Rooy (M.de.Rooy at rijksmuseum.nl) wrote:
> > Hi Paul, all,
> >
> > > * Release the 3.X.0 saying it's a beta, could have some bugs not
> detected. The 3.X.1 being a RC, and the 3.X.2 being the 1st really
> stable version.
> > +1 for this second option. You could say that it makes more formal

> > +what one could already suspect about a 3.X.0 release.. No real change
> > +in workflow.. (3.X.1 being stable might be nice too :-)

>
> I think I prefer the first option, or at least that is what we should be
> aiming for. Aiming for a stable release at the .1 or .2 level will mean
> it wont be stable until .3 or .4.
>
> But as the elected release manager for 3.10.0 it's your call, and I will
> work with whatever you decide.
>
> I think this is also a good time to start thinking about 3.12.x
>
> http://wiki.koha-community.org/wiki/Roles_for_3.12
>
> Chris
>
>
> --
> Chris Cormack
> Catalyst IT Ltd.
> +64 4 803 2238 <tel:%2B64%204%20803%202238> 
> PO Box 11-053, Manners St, Wellington 6142, New Zealand

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120712/13b4863c/attachment-0001.htm>