Development and release model? - Multiple branches? (was: [PATCH 0/8] maintenance patches)

[Andreas Metzler]

On 2016-01-04 James Youngman <address@hidden> wrote:
> On Mon, Jan 4, 2016 at 8:11 AM, Bernhard Voelker
> <address@hidden> wrote:
[...]
>> b) Do you want me to push to the 4.6 branch, too? (see c)).

>> c) Will we maintain a 4.6 and a 4.7 line in parallel (although
>> we don't have anything big for master)?  I must confess that
>> I'm a bit confused with this model. Other projects just leave
>> bug fixing up to downstream distributions which can pick commits
>> as they like.
[...]
> b) Sure, go ahead and push patches to the 4.6 branch.    Generally
> yes, for low-risk patches.

> c) I'd like input from the other committers and from the principal
> downstream consumers (e.g. Andreas, Kamil) before making a choice,
> since it's the committers who would need to maintain the parallel
> branches and the downstream maintainers who (allegedly) benefit.
> Let's have a data-based discussion about what works for everyone - in
> a separate thread, I'd suggest.
[...]

Hello,

throwing in my 2c as Debian packager:

Imho at least until there are invasive changes with the potential to
prevent a stable release on this codebase for months there is little
to be gained by findutils having a development branch. Is there
something like this pending? (If there ever is I hope it is possible to
do this with a feature branch, i.e. a living master with releases and
a feature branch that syncs to master until it is stable.)

Debian's release/development process basically works like this:
============================
Debian/sid (unstable) will usually be in sync with upstream's latest
  stable release. I might also use a development version to give it
  wider testing if I am positive it will be stable once Debian thinks
  about a release. I might also pull selected patches from GIT to fix
  serious bugs.

Debian/testing automatically inherits packages from unstable after a
testing period if they do not introduce new rc bugs.

When we consider a release we stop invasive changes to sid and once
testing is good enough we branch it of as our new stable release. Once
it is declared stable updates mainly happen for security issues,
(fixes of important bug are possible), but for anything except the
software where we have given up on it (firefox) this happens with
minimal patches, not by uploading new upstream releases.

(There is also an experimental repository, mainly used for testing
buildabilty before uploading to sid.)
============================
So there is no good place in Debian for alpha releases or software
that might stay unstable for a long time, which boils down to another
vote for a single branch model with regular releases.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'