> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
