On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan <pe...@2ndquadrant.com> wrote:
> On 11 April 2012 15:35, Magnus Hagander <mag...@hagander.net> wrote:

>> 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.

Particularly for the docs, it'd be nice to have more committer
bandwidth available, if there's a reasonable way to do so without
causing needless merge work for existing committers. Like Peter, I
hate to bother busy committers with trivial typofixes, and sometimes I
just don't bother sending such changes in, and they get lost :-(

Maybe keeping doc/ as a 'git submodule' could work? Or, as Tom
suggests, adding a global committer who could focus on docs changes
would effectively solve the problem as well.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to