| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Joe Conway <mail(at)joeconway(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Commitfest problems |
| Date: | 2014-12-20 04:17:54 |
| Message-ID: | 5494F872.6000105@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/19/14, 6:16 PM, Tom Lane wrote:
> Could we establish an expectation that whoever sets a CF entry to "ready
> for committer" is responsible for reviewing the authors/reviewers lists
> and making sure that those fairly represent who should get credit? That
> would divide the labor a bit, and there would also be time enough for
> corrections if anyone feels slighted. The idea's not perfect since major
> contributions could still happen after that point; but I think the major
> risk is with the committer not remembering people who contributed early
> in the patch's life cycle, and we could certainly hope that such people
> get listed in the CF app entry.
Perhaps go even one step further and let a reviewer draft the actual commit message? That would further reduce committer workload, assuming the committer agrees with the draft commit message.
> Alternatively we could abandon the practice of using the commit log for
> this purpose, which could simplify making after-the-fact corrections.
> But then we'd have to set up some other recording infrastructure and work
> flow for getting the info into the release notes. That sounds like a lot
> of work compared to the probable value.
git does allow you to revise a commit message; it just makes downstream pulls uglier if the commit was already pushed (see https://help.github.com/articles/changing-a-commit-message/) It might be possible to minimize or even eliminate that pain via git hooks.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-12-20 05:15:04 | Re: Commitfest problems |
| Previous Message | Jim Nasby | 2014-12-20 04:03:55 | Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber) |