On 04/17/2012 11:29 PM, Andrew Dunstan wrote:
>
>
> 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.
years ago when I did the PoC install for PostgreSQL i used the
RPC-Interface for replacing the bug-reporting form on the main website,
it was prett ylimited back then (especially around authentication and a
way to actually make the report show up with the reporters name (which
very likely does not have a BZ account), but all those were solvable. BZ
really has the drawback that it is kind of a monster on the featureside
and you need to invest some significant time to make the UI
understandable before you can actually present it to a wider audience.
Stefan
