On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander <mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
