| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jay Levitt <jay(dot)levitt(at)gmail(dot)com> |
| Cc: | Greg Smith <greg(at)2ndQuadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Alex <ash(at)commandprompt(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bug tracker tool we need |
| Date: | 2012-04-17 20:38:14 |
| Message-ID: | 15479.1334695094@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jay Levitt <jay(dot)levitt(at)gmail(dot)com> writes:
> Greg Smith wrote:
>> Tracking when and how a bug is backported to older versions is one hard part
>> of the problem here.
> That's a great point. Both GitHub and git itself have no real concept of
> releases, and can't tell you when a commit made it in.
We do actually have a somewhat-workable solution for that, see
src/tools/git_changelog. It relies on cooperation of the committers
to commit related patches with the same commit message and more or
less the same commit time, but that fits fairly well with our practices
anyway. If we did have an issue tracker I could see expecting commit
messages to include a reference to the issue number, and then it would
not be hard to adapt this program to key on that instead of matching
commit message texts.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-04-17 20:42:56 | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap |
| Previous Message | Tom Lane | 2012-04-17 20:33:37 | Re: Parameterized-path cost comparisons need some work |