Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision)

[Graham Percival]

On Wed, Aug 01, 2012 at 03:21:34PM +0200, David Kastrup wrote:
> Graham Percival <address@hidden> writes:
> 
> >> If it is non-operative, it should be either made operative or removed.
> >> There is no point dragging it along as purely dead weight we should not
> >> be using.
> >
> > Sure, patches appreciated.
> 
> You know that this comes across as "In my opinion nobody but the foolish
> person asking for this should think of working on that problem."?  I am
> staking out the requirements I need to get the appointed job done.
> Unless you have some reasonable suggestions how to get around those
> requirements, I see little point in discouraging others from helping
> with them.

I apologize; you are quite correct.


> > I'm missing something.  What's wrong with this scenario: - I
> > release 2.15.42 today or tomorrow.  - you branch stable/2.16
> > from that.  - in a week I release 2.17.0.  - you do whatever
> > you want with 2.15.43, 2.15.44, etc, until you reach 2.16.0.
> > Other than probably having no syntax changes because I really
> > don't know how that can be juggled.
> 
> There will be no syntax changes in the 2.16 branch, at least not
> of the convert-ly kind (one reasonably established syntax to a
> different intended one).

Shall I go ahead and do 2.15.42, then?

> >> 2.15.95 would presumably protest against snippets already
> >> being at 2.16.0.
> >
> > The final change of version numbers it the last thing we've
> > done in the past, and just tested on my local machine with
> > make doc.
> 
> Hm.  At any rate, it seems strange to have 2.17.0 released and
> no recognizable disruption in the 2.15 release series while 2.16
> is not finished.

Well... I agree that it's a sub-optimal situation.  But this is
the least disruptive (in terms of development) and least
resource-intensive (in terms of fighting with build systems)
manner I can think of.  I think we can live with a bit of
strangeness.

If we had experts actively maintaining our build system and GUB
(people such as Jan, John, or Julien [1]), I would be much more
interested in discussing ideal policies for users and developers.
Or even if we had no experts but I had time and interest to fight
with GUB.  However, at the present time we lack either experts or
non-experts with excessive interest in GUB.  So I reluctantly
recommend that you optimize the 2.16 policies for a lack of build
system changes.  If the situation changes (say, Julien finishes
university and gets sponsored to work on lilypond full-time, or
you get a computer capable of compiling GUB), then of course I
would withdraw that unpleasant recommendation.

[1] I would have added your name to the list, but it doesn't begin
with a "J" in alphabetical order of chronological order of working
on the build system.

- Graham