On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 11 April 2012 15:35, Magnus Hagander <magnus@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.
Josh
