On 04/17/2012 04:38 PM, Tom Lane wrote:
> Jay Levitt<jay.levitt@gmail.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.
>
>
Yeah, that would be good.
BTW, since we're discussing trackers yet again, let me put in a plug for
Bugzilla, which has mature Postgres support, is written in Perl (which a
large number of hackers are familiar with and which we use extensively),
has a long history and a large organization behind it (Mozilla) and last
but not least has out of the box support for creating updating and
closing bugs via email (I just set up an instance of the latest release
with this enabled to assure myself that it works, and it does.) It also
has XML-RPC and JSON-RPC interfaces, as well as standard browser
support, although I have not tested the RPC interfaces.
cheers
andrew