[Koha-devel] About Release process

[Ian Walls]

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
> > 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/b7c20b3a/attachment.htm>