distro branches on sourceware

[Roland McGrath <roland at hack dot frob dot com>]

> i've been debating doing this for a while ... half wrote an e-mail proposing a 
> new Gentoo namespace a few times.

Anyone (like you) who already has commit access and is authoritativish
for a downstream packager is more than welcome to establish a branch
namespace without anyone else's say-so.  Just stick to some common sense
and collaboration-friendly rules and then just do it: pick a name that
is all lowercase, includes minimal or no punctuation (i.e. some internal
dashes if they make sense, and no other nonalphabetics, ASCII only), and
is well-recognized for your system (fedora, gentoo, archlinux, debian,
suse or opensuse, etc.); choose the rules for the namespace's use and
document them on the wiki; follow common conventions unless there's a
reason not to (e.g. yourprefix/master, yourprefix/2.34/master, etc.);
post about what you're doing.

> i've gotten most patches merged at this point, so i wasn't sure how much
> of an advantage it would bring.

The theory behind this is that even in the shangri-la future where
everybody is using exactly the same unmodified canonical code, it will
still be useful.

* Even for changes that are temporary, kludgey, or permanently
  distro-specific, having them on a sourceware branch makes it easy for
  everybody to see what you're doing.  A maintainer for a different
  distro might look at how you've addressed a packaging need or a user
  problem, like your idea, and be saved some work discovering the same
  details.

  The same goes for scripts and packaging magic specific to your system
  as well as actual code changes.  For example, the old fedora/master
  branch includes both the glibc.spec file used to drive rpmbuild, and
  the scripts and makefiles used to drive updating that, importing into
  the Fedora build system, doing merges on the branch itself, etc.

* The main thrust of my original plan about public distro/vendor
  branches was about per-release distro branches forked from the
  communal releases/... branches.  The concept is that every time a
  downstream maintainer found a bug and whipped up a patch, they'd put
  the change on their public branch and update it there as they updated
  what they deliver to their users.  When a maintainer wanted a
  particular trunk fix backported to their release stream, they'd start
  by just doing the cherry-pick onto distro/2.34/master, cooking
  releases for their users and testers, and iterate until confident.  

  In the imagined future where every well-maintained distro has an
  active distro/2.34/master branch, then the maintenance of
  release/2.34/master would be an all-but-automatic task of collecting
  the trunk backports that the consensus of active distro maintainers
  want on their distro/2.34 branches.  The theory goes that if no distro
  cared to backport it and deliver it to their users, then it doesn't
  belong on the communal release branch either.

  Other distro maintainers might track your branches to preemptively
  notice and consider issues that hit your users before any of theirs
  noticed or reported them.

> i've got pretty clean history for every patchset we've ever released (except 
> perhaps during the turbulent 2.3.x time where releases were officially 
> discontinued), so i could probably import our history.

I'm not sure that such old history is really useful to have in the
communal repository.  (But, do what you like in your own branch
namespace.)  The main utility of the branches is to display what you're
using today in any release stream still being maintained now.  Of course
having the rationale for each change explained somewhere and that
somewhere easily found (have it in the repo, have pointers to it in the
repo, whatever) is essential too.  And another major motivation of the
whole idea is to have downstream maintainers migrate to doing their
maintenance work in upstreamy ways, so whatever facilitates that is good.


Thanks,
Roland