Re: Last gasp - Mailing list pgsql-hackers

On 11 April 2012 15:35, 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? 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...

This is hardly a radical idea at all - it's basically how git was
really intended to be used at scale. Of course, unless some committer
is going to make it their responsibility to merge those commits say
every 3 months, there's no point in bothering. This could consolidate
the number of typo commits to boot, as they could be rebased. TBH, I
find it slightly embarrassing to have to ask a committer to fix a
minor typo, and it's hardly reasonable to expect me to save my typos
up.

Big +1 from me.

It might be the case that over time, we become comfortable with this
approach and upgrade the tree to a "linux-next" style tree (much like
the  -mm tree was repurposed into the progenitor of linux-next), with
a lesser (though still substantial) standard for committers to meet.
There could be an understanding that by committing to the tree, the
developer makes a representation that they are confident that the
feature is ready for prime-time, in just the same way that a commit
currently represents - don't underestimate the power of that ceremony.
Less senior contributors could have their work scrutinised by a wider
body of people that haven't necessarily taken enough of an interest in
the contributor's work to want to follow them on github or whatever -
enthusiast power users who wouldn't really consider themselves
hackers.

This partially solves the "you want us to fund feature development but
you're not even a committer?" problem that Greg referred to. It's also
how big projects scale - technically, there are relatively few
committers to the linux-stable tree.

This approach formalises Tom's view that "I think the key point here
is that people have to expect that it's going to take more than one
round of review to land most nontrivial patches".

On 11 April 2012 16:27, Robert Haas <robertmhaas@gmail.com> wrote:
> 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?

This seems like a non-issue to me. We just try and match the Linux
model. In practice I'd imagine that the roles would not really be
perfectly delineated like that, and I find it really doubtful that
they are in Linux land either. There was a time when some people were
somewhat skeptical of the git migration (at least privately), and that
was, as far as I can tell, a roaring success.
--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services