Re: Last gasp
Josh Kupershmidt <schmiddy@gmail.com>
From: Josh Kupershmidt <schmiddy@gmail.com>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Magnus Hagander <magnus@hagander.net>, Tom Lane <tgl@sss.pgh.pa.us>, Greg Smith <greg@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-04-11T16:29:10Z
Lists: pgsql-hackers
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