Re: branching

[Mike Solomon]

On Dec 10, 2013, at 4:23 PM, David Kastrup <address@hidden> wrote:

> Mike Solomon <address@hidden> writes:
> 
>> Hey all,
>> 
>> As 2.18 draws near, I’d like to work with everyone to establish a
>> system of branching for LilyPond development.  After several rounds of
>> discussing things with David K, this emerged as the best way to avoid
>> arguments about integrating work into the development branch that have
>> led several contributors, including myself, to significantly reduce
>> time on the project. [1]
> 
> It will take me considerable time to address this more thoroughly, but
> in the mean time I want to have on record that what Mike writes here
> under "this emerged as the best way" _not_ in _any_ way summarizing our
> discussion.  Instead it is his _personal_ idea how to address topics we
> covered.  Writing something like "this emerged as the best way" when we
> did not even talk about it wrongly insinuates that it presents a common
> understanding of how to address problems covered in the discussion.
> 

Sorry, I in no way mean to apply that this is a proposition on David’s behalf.  
This is a proposition from me that it is a response to our discussion, not a 
summary of it.

> Feel free to quote passages or complete mails from me in the course of
> that discussion: there is nothing in there that I would not have equally
> said in public.


(quotes from David)

The basic idea behind that is not to make confrontations nicer but
reduce the necessity for them by establishing playing fields with
different authorities.  So that people can get work done without
endangering the release, and I can get releases done without pissing
people off as a prerequisite.

We won't be able to completely separate the two, but both our current
code base and our current development model are quite bad for getting
this under control.

…

As I said: there are certainly decisions where a vote does make sense:
mostly when there is a choice between alternatives.  For "go ahead or
not" kind of decisions, the answer should likely be "go ahead in a
sandbox, and with enough exposure of the sandbox to testers and end
users, we'll be better equipped to make an informed decision".

That's how it tends to work with the Linux kernel, but both our code
base as well as our infrastructure is not really diverse enough to make
this easy.  It _would_ be easier in a Scheme universe, or with loadable
C++ modules.  But either case requires that enough of the internals are
implemented through exchangeable interfaces that swapping out key parts
for user-written code can be done without disrupting too many unrelated
parts in the process.

…

My proposal is a first-pass at starting a dialogue about this that people can 
respond to - I expect some or all of it to be rejected, but the important thing 
is to start talking about it now.

Cheers,
MS