On Wed, Apr 11, 2012 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> Might it be worthwhile to allow some sort of "staging repository" and
>>> actually start using the git stuff a bit more around this?
>
>> ... 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.
>
> Yeah. I'm also worried that we would either lose linear history, or
> (if we squash the merge commits) lose change log history for the
> individual fixes. Neither of those sounds terribly attractive.
>
> We've frequently had, and still have today, committers who are
> understood to have limited areas of expertise and are given commit
> bits on the honor system to not break what they don't know well.
> I don't have any problem with continuing in that line.
Me neither, but I don't know how far it scales. Having certain people
who are defined as, say, doc-only committers will not only make it
clear to those people what they're expected to commit, but also clear
to everyone else who the people are who might commit any given patch
they might write. If we just end up with 50 committers and you have
to follow pgsql-hackers to understand who knows what and which people
are even still around, it's not going to make anything easier for
anyone.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company