On Apr 15, 2011, at 3:40 PM, Carl Sorensen wrote: > > > > On 4/15/11 12:32 PM, "Matthias Kilian" <k...@outback.escape.de> wrote: > >> [random notes from soneone who is *not* actively hacking on LilyPond, >> so feel free to ignore it ;-)] >> >> On Fri, Apr 15, 2011 at 03:29:52PM +0100, Graham Percival wrote: >>> The reason that I'm pessimistic is that we racked up a huge amount >>> of "technical debt" (i.e. bugs) during 2.11 and the early phase of >>> 2.13. I'm concerned that if we don't have regular releases, the >>> unstable branch is going to accumilate bugs. >> >> Well, I think I've written this a few months ago: (stable) releases >> *must* happen more often (at least one or two times a year) if you >> want to be able to cope with stable and unstable. >> >>> I am also too tired to fight over it right now, but I also think >>> that this is the wrong model of branching. There's basically two >>> ways: >>> 1. keep master in a "ready-to-release" mode at all times; any >>> serious bug gets reverted or fixed ASAP. Unstable development >>> happens on separate branches, which are merged to master when >>> they're ready. >>> 2. toss whatever garbage you want onto master, and make a "stable" >>> branch where a bunch of poor suckers cleans up the branch until >>> it's ready for a release. >> >> 1. is the way to go. Sure, it would put some pressure on people >> working on big changes, which kind of sucks (it could even slow >> down implementing cool new stuff). On the other hand, it enforces >> smaller steps towards new features, which is good (easier to track >> down regressions, easier to *understand* what's going on). > > This is what we've been doing for the past 4 months or more. > > How do we define the difference between "stable development" and "unstable > development"? It seems to me that "stable development" means we pass the > regtests -- we've been doing that for at least a couple of years. But we > still end up with regressions when users test the code beyond what the > developers have tested. >
I agree - it is for this reason that I feel the only two solutions are to: (1) Freeze pushes to the master branch save ones that are explicitly authorized by Graham. (2) Keep working at our normal pace, but split off stable versions to which only bug fixes will be applied. The idea that an unstable version should turn into the default new stable version has always appeared problematic to me. I know nothing about how large computer projects work, but as a performance artist, I always freeze my shows a week before the show and only fix things that technically don't work. I'm always developing new material, but I don't ever do anything less than a week old because I don't have the critical distance from it to know if it's good or not (save my 24-hour show binges, for which anything goes!). In the same vein, I think that if we split off a new release candidate and then cherry picked critical bugfixes into it, it would prevent the type of bugs that arise from continued work on making LilyPond great (like the beam-collision problem through which we're currently wading). > As long as we have a policy that any regression will delay a stable release > for two weeks, it seems to me that we *must* stop adding features in order > to get a stable release. We can't prevent unintended regressions. > Agreed - irrespective of the policy we choose, I will not be adding any new features before 2.14.0 and will only do bug fixes. > OTOH, if the standard for "ready-to-release" were "make check succeeds and > no segfaults have been identified", then we've been ready to release a > stable version for a long time now. I think the nature of LilyPond is such that no number of regtests can adequately encapsulate the potential failures of the program. Furthermore, some of the most problematic bugs cannot be anticipated by developers because it is hard to take stock of the regtests before pushing a patch and say "what eventualities do all of these regtests combined fail to cover?" Having a new branch incubating somewhere between stable and unstable seems to be a way to mitigate the effects of this uncertainty by freezing LilyPond's evolution save certain critical situations. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
