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