Re: community long term x.y release branches

[Karl Berry]

i would like to help coordinate these downstream distros so they don't have
to keep all repeating the same work.  basically:

Sounds sensible to me.

* commits are on a volunteer/request basis -- there is no
  expectation that people working on master/whatever think about
  these older branches

I like that in particular :).

* maybe we cut a new release once a year from those branches if any
  changes were actually made to them.  i would like this, but even
  if we do all the other things above and omit this, i'd still be happy.

Sounds reasonable, not that I'd be the one making such releases.
I'm guessing Jim would want to push making such "back releases" to you ...

so since the last release is still 1.16.z, the newest such branch
would be refs/heads/release/1.15 and it would start life at v1.15.1.

Fine by me. 

Jim, can you chime in? As you know, I have little clue about git
development conventions, so can't make any sensible comments at that
level.

BTW, the next release will surely be 1.17. Some of the stuff I already
did in the 1.16.x releases really should have provoked 1.17, but I just
didn't adhere strictly to the rules (because I didn't know about
them). --thanks, karl.

community long term x.y release branches

[Mike Frysinger]

as folks are aware, some projects require specific versions of autotools.
the exact reasons don't matter (e.g. committed files ala gcc/binutils/gdb,
working on an old branch/release, etc...).  i'd like to focus on one part:
downstream distros will often carry backports to keep older versions working.
they aren't a lot of backports, but it's certainly more than zero.  new perl
incompatibilities or warnings tend to be the biggest source.

i would like to help coordinate these downstream distros so they don't have
to keep all repeating the same work.  basically:
* create a new ref namespace under refs/heads/releases/
* once a new x.y release has been cut, branch the previous release there
* the branches are open to backports, and on a very strong focus of only
  fixing bugs, and minimizing codegen related changes
* new features are not allowed at all
* commits are on a volunteer/request basis -- there is no expectation that
  people working on master/whatever think about these older branches
* maybe we cut a new release once a year from those branches if any changes
  were actually made to them.  i would like this, but even if we do all the
  other things above and omit this, i'd still be happy.

so since the last release is still 1.16.z, the newest such branch would be
refs/heads/release/1.15 and it would start life at v1.15.1.

we're already doing this work in Gentoo for sure, so it's not extra work
for us.
-mike


signature.asc
Description: PGP signature