Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf,
> * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:30:32AM CEST: > >>I propose that we move from a feature driven release policy to a time >>based one. After 2.0, we should aim for a stable release (say) every >>3 months, with a feature freeze in the last six weeks. To maintain >>forwards momentum, and prevent another embarrassing 2.0 like debacle, >>I think that every second one of those should come from HEAD. I think >>that as long as we forward port bug fixes from the last release branch >>as they are applied, we should only need to maintain 2 branches at >>once. >> >>So in the future, assuming we start the process next year, our release >>schedule should look something like this (not taking into account >>public holidays and slipping to the nearest weekend): >> > > *snip* > >>We can always choose to stick with a troublesome stable branch for >>longer if it turns out to need more work to iron out any bugs and >>regressions rather than ploughing on with another head release... >>thoughts? > > > Yes, just one: this is INSANE. > > Gary, haven't you burnt yourself enough with promising releases at > certain times? This is because we are locked in a feature based release policy. I think moving to a time based policy will make this problem redundant. > You talked about 2.0 being close more than a year ago, it's not out. Agreed. And the fault there was piling in more features without stabilising the existing ones. > A few weeks ago you talk about it being possible in about two weeks, > yet today I see patches with large "necessary" changes. We're still fighting with that feature based release... > Have you > ever thought that, before a release, things should get quieter, less > intrusive, and not the other way round? And that promises not kept > reflect badly? All the time :-( That's why I'm proposing that we move to a time based release policy! > Also, my time investment in Libtool is not sustainable at the current > amount. I see others coming and leaving as well. With this, any kind > of deadline promises is just fooling oneself and making this project > look very bad. Nor mine. And I agree that much work needs to be done in stabilising before we add any new features. During that time (and beyond if we keep the release times in mind when adding a feature), there is nothing to stop us putting out timely quarterly releases which will be more stable than the last. > And regarding forward momentum: if you need a playground to put un- > finished ideas in that later turn out to be unfixable or need large > intrusive fixes: this is not the way to go for a project other ones > depend upon in order to function! Not at all! ACK. Feature branches may be the right way to do this in future? My point about forward momentum was that if we only open the tree for new features for a few weeks after a release, and spend the rest of the time stabilising the code base with the aim of making quarterly releases things should continue to improve. Doing half yearly or annual releases would be worse IMHO because there will be the temptation to dog pile features again. > If you really think someone could commit on maintaining more than one > branch at a time, I would like to see some commitment on this. I for > one am not paid to do any work on Libtool. And there are still lots > of bug reports (against branch-1-5 as well as HEAD!) open and > unfinished, for real issues with libtool that other people care about. Sure, so we have a moratorium on new features *entirely* for future time based releases until all of this is under control. That seems much more sane to me than continuing as we have. My argument for 2 branches is that bugs will be reported against the most recent stable release as often as not, and fixing them there and forward porting seems to be the right approach. Making a routine time based release from that stable branch with the accumulated fixes is a good thing. Notice that in my proposal we make an alpha from the trunk at the same time as a maintenance release from the stable branch, and then spend the next quarter stabilising the alpha before it becomes promoting to stable twice a year... effectively each branch lives for one year. 3 months in alpha, 3 months as an unstable release while the previous stable branch is maintained, 3 months as a stable release while the new features can be added on the trunk and 3 months as a maintenance release. I'm not hellbent on quarterly releases at all, it just seems like a reasonable time period and the symmetry is pleasant and requires only 2 branches. > I do not mind the goal of frequent releases at all, I just won't commit > to any kind of timetable, and, more importantly, I won't commit to > releasing from a yet unknown "development tree" with whatever broken > features. Agreed, but that is still a feature based mindset. Broken features can only be added in the first half of the first quarter of a branch's life cycle, and should be satisfactorily stabilised before adding anything else new. The implication is that even after 2.0, we need to focus on stabilisation... but that shouldn't prevent us from making quarterly releases that are each better than the previous one! > Forwards momentum is not gained by policy or talk, it's > gained by commitment, and as the result of work being done. And _then_, > the achieved work can act as a natural good measure of when it is useful > to have a new release. And yet that mindset has made us put so much stuff into the 2.0 release that we haven't been able to stabilise it fast enough to release. However, I do take your point: it WOULD be insane to push any release out when we know it has serious bugs in it, and we certainly shouldn't fall prey to that. Ignore the dates from my other mail, and even the quarterly schedule if you wish... I think we should discuss the merits of moving to time based releases with an eye towards preventing feature creep in the future. Cheers, Gary. P.S. I do realise that this thread is controversial and inflammatory, but it is certainly not my intention to upset anyone, just to fuel discussion about exploring a better way to handle releases in the future. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature