Re: stable/2.12 and tagging of tarballs

[Han-Wen Nienhuys]

[oops - forgot the list]

On Tue, Jun 9, 2009 at 12:15 PM, Han-Wen Nienhuys<address@hidden> wrote:
> On Tue, Jun 9, 2009 at 11:36 AM, Graham
> Percival<address@hidden> wrote:
>> On Tue, Jun 09, 2009 at 08:07:57AM -0600, Carl D. Sorensen wrote:
>>>
>>> On 6/9/09 7:56 AM, "Jan Nieuwenhuizen" <address@hidden> 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 - address@hidden - http://www.xs4all.nl/~hanwen
>



-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen