Nothing to say against that, of course :) Option 1 is/has been our goal, but what actually happened was option 2..
Van: [email protected] [mailto:[email protected]] Namens Ian Walls Verzonden: donderdag 12 juli 2012 13:50 Aan: Fischer, Katrin CC: [email protected]; 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 <[email protected]<mailto:[email protected]>> 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: > [email protected]<mailto:[email protected]> > [mailto:koha-devel-<mailto:koha-devel-> > [email protected]<mailto:[email protected]>] On > Behalf Of Chris Cormack > Sent: Thursday, July 12, 2012 12:22 PM > To: Marcel de Rooy > Cc: > [email protected]<mailto:[email protected]> > Subject: Re: [Koha-devel] About Release process > > * Marcel de Rooy ([email protected]<mailto:[email protected]>) > 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 [email protected]<mailto:[email protected]> 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/
_______________________________________________ Koha-devel mailing list [email protected] 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/
