dist-git proof of concept phase 2 ready for testing

[Roland McGrath]

> Right, but when I as a releng person need to bump something in an
> emergency or when a maintainer is out, I expect origin/master to be
> "live" for rawhide, ditto origin/F-12 for Fedora 12.  I don't expect
> that I'd have to go hunting down where the commit hash for the previous
> build came from, then try to discover which branch that commit hash
> currently lives on, so that I can commit on top of it and keep going.

Ok.  But, chances are that builds from branches are for temporary
situations (emergency updates while bigger updates are in testing, etc.)
and the circumstance where the obvious tip is not the same as the last
build will be rare.

My real point was that such situations will be entirely well-defined in a
mechanical sense.  So it's always possible to automate an "F-n/master is
not an ancestor of most recent dist-fn build" check, make it autoflame
maintainers every day, etc.

Certainly I don't think that releng people should be expected to do commits
on random branches that maintainers happen to be using.  I can't really
imagine that a maintainer really ever wants that.  But once each of those
"go hunting down" and "try to discover" steps is entirely automated with
100% reliably correct answers in an instant, as should certainly be quite
simple in git, then the picture of absolute necessity for a priori controls
on how maintainers do all their business looks a bit thinner.  That's all.


Thanks,
Roland