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. Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
