[oops - forgot the list] On Tue, Jun 9, 2009 at 12:15 PM, Han-Wen Nienhuys<hanw...@gmail.com> wrote: > On Tue, Jun 9, 2009 at 11:36 AM, Graham > Percival<gra...@percival-music.ca> wrote: >> 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? > > This is completely backwards: the definition of a stable release (or > rather: stable branch), is that it is bugfix only. Avoiding having > bugfixes defeats the entire purpose of a stable branch. > >> 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. > > This sounds wrong: if people have the capacity to decide whether or > not a patch can be applied to master, they certainly have the ability > to decide whether a patch can be cherry-picked into stable. For the > 2.10 branch, I would every once in a while cherry-pick all small > bugfixes that applied to 2.10 and roll a new 2.10 release. I kept this > up until patches started to conflict. > > Since I have seen some issues in the tracker with the tag > fixed_2_13_x, it is worth a look to see if there is anything missing. > >> 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 > > You should not be comfortable with this. LilyPond is an open source > project without dependable dedicated workers. The notion that some > release will be ready in X months laughable. If you are doubting this, > look at the history of our releases: when we thought they were ready, > and when we really released. > >> 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. > > -- > Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen >
-- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
