On Tue, Jun 09, 2009 at 08:07:57AM -0600, Carl D. Sorensen wrote: > > On 6/9/09 7:56 AM, "Jan Nieuwenhuizen" <janneke-l...@xs4all.nl> wrote: > > > I propose to release a buildable 2.12.3 tarball, and to have name a > > stable and a development branch. Numbering isn't all that interesting, > > but linux also has that: you need [at least] two [more or less] active > > branches if you are willing to do some kind of sane release management. > > IMHO, of course :-) > > I don't want to speak for Graham, but I think the original proposal was made > to avoid development effort spent in backporting. But I can't think of a > good way to avoid backporting if it's desired to have bugfixes on the stable > release.
That's true. However, I chose to avoid having bugfixes on the stable release. It's a simple question of resource allocation -- how can we make best use out of the limited resources? Who here is capable of backporting? I don't just mean doing the git stuff, but evaluating what's worth backporting, making sure that those patches don't wreck anything or depend on anything else, etc. Han-Wen, Jan, Joe, John, Werner... maybe Carl, Reinhold, and a few other people. What's the common factor? Other than technical excellent and a love of open source, these people are all _very_ busy. I'm more than capable of recruiting and training people to do various tasks -- documentation, LSR editing, checking the regtests, etc -- but I *don't* think that I can take a newbie and turn them into a backporting person in a few weeks. Let's look at the problems in the 2.12.2 release, shall we? 1. the tarball didn't match the actual build from git. Whoops, that sucks... but the release obviously *did* build, so if we're more careful about tarball generation, then that won't be a problem. 2. broken Japanese translation. If 1 wasn't a problem, then this wouldn't matter (the release obviously _did_ build). This could have also been avoided by not adding it at the last moment; we should have waited for 2.13 for this. 3. no gcc 4.4 patches. That's a rare occurrence; I don't know if gcc screwed up before 4.3, or screwed up in 4.4, but this shouldn't be a problem in the future. 4. ... IIRC there was something else, but I forget what it was at the moment. I'm entirely comfortable telling people "wait for 2.14; it'll be out in 3 months" if these problems were discovered two weeks after 2.13 was started. For package mainteners, we can point them at the patches for #3. As long as the tarball builds on the system requirements we list, I think we should just tell people to wait, and spend our time working on that new release. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
