On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander <magnus@hagander.net> wrote:
> Since the topic is somewhat drifting here anyway.. :-)
>
> Might it be worthwhile to allow some sort of "staging repository" and
> actually start using the git stuff a bit more around this? E.g. we
> could have a "docs repo" somewhere where more people have commit bits,
> and then they are just regularly merged back into the main tree? Sort
> of the way different people can own different subsystems in other
> projects, but someone does the "trusted merge"?
>
> For example, Thom (and others) could collect a number of typo fixes in
> their own repo and then just ask for a merge.The advantage over just
> staging multiple commits and then submitting a patch would be that
> multiple people could work on it...
If our goal is to give people more or less unfettered access to
certain areas of the tree, but not the whole thing, we should perhaps
consider just doing that directly. There's no particular reason why
Thom Brown can't be made a committer just for docs, or why Alex
Hunsaker can't be made a committer just for PL/perl (and presumably
docs, since he'd need to update the docs if he updates the code), if
that's actually what we want to do.
Now, the advantage of a staging tree is that it gives the people who
have commit rights to the main repository the ability to decline to
merge. The question is - what happens then, especially given that we
have so many committers already? In Linux-land, it becomes the
subsystem maintainer's responsibility to put the tree into a state
where Linus will again become willing to merge it, or he can fire the
subsystem maintainer and pick a new one that'll do what he wants. But
we don't work that way. Instead, the committers as a group have the
responsibility for not breaking stuff. So who would decide whether to
do the merge, and who would be responsible for fixing things if the
merge were refused? As far as I can see, this basically amounts to
bundling lots of unrelated changes into one big pile and then asking
to have them all committed at once instead of one at a time, which
sounds like more work not less, unless we're just going to blindly
merge without reviewing, in which case we may as well just let people
commit to the main repository themselves.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
