Re: No Issue Tracker - Say it Ain't So!] - Mailing list pgsql-hackers

On 10/04/2015 03:42 PM, Nathan Wagner wrote:
> I downloaded the archives for pgsql-bugs, and fed them into a database.  This
> part was easy, since I have already written a pg backed usenet server and had
> the code hand for storing and parsing out bits of rfc 2822 messages.

That would be the key part, wouldn't it?  Nice that you have that.

So this would be the other option if adopting debbugs doesn't work out.I think it's likely that we'll end up recreating
mostof debbugs in the
 
process (or bugzilla or something else) but whatever.  As long as we
have some kind of bug tracker, I'm happy.

> It's dirt simple.  If the system sees a message with 'Bug #(\d+)' in the
> subject line, it creates an entry in a bugs table with that bug number (if
> needed), and then marks the message as belonging to that bug.  If there seems
> to be metadata about the bug in the format of the (unquoted)
> 
> Bug reference:
> Logged by:          
> Email address:
> PostgreSQL version:
> Operating system:
> Description:
> Details:
> 
> it pulls that out and puts it in the bugs table.  There's also an "open"
> boolean in the table, defaulting to true.
> 
> The results can be found at https://granicus.if.org/pgbugs/
> 
> Ok.  So now we have a bug tracker, but...
> 
> Some open questions that I don't think have really been addressed, with my
> commentary interspersed:
> 
> 1: Can a bug be more than "open" or "closed"?
> 
> I think yes.  At least we probably want to know why a bug is closed.  Is it not
> a bug at all, not our bug, a duplicate submission, a duplicate of another bug,
> something we won't fix for some reason (e.g. a bug against version 7)

We'd want the usual statuses:

* fixed
* duplicate
* unreproduceable
* timed out
* not a bug
* won't fix
* reopened

We'd also want a way to link a bug fix to a commit, and probably a way
to give the bug a list of searchable keywords (and add to that list).

> 2: Who can declare a bug closed.
> 
> Ugh.  I'm going to close some of them if it seems obvious to me that they
> should be closed.  But what if it's not obvious?  I could probably maintain it
> to some extent, but I don't know how much time that would actually take.
> 
> Related to the next point, it probably makes sense to just close up front
> bugs that are marked against unsupported pg versions, or haven't had
> any activity for too long, perhaps two years.  Just closing bugs with no
> mailing list activity for two years closes 5280 of 6376 bugs.

I'm reluctant to close all of those unexamined, since part of the
purpose of this is to find bugs which were never fixed.  Probably we
should organize a posse to comb trhough all of the old bugs and
hand-close them.

> 3: How far back should I actually import data from the bugs list?
> 
> I have imported each archived month from December of 1998.  It looks like the
> bug sequence was started at 1000 in December of 2003.  Emails with no bug id in
> the subject line don't get associated with any bug, they're in the DB bug not
> really findable.
> 
> 4: What should I do with emails that don't reference a bug id but seem to be
> talking about a bug?
> 
> I suggest we do nothing with them as far as the bug tracker is concerned.  If
> people want to mark their message as pertaining to a bug, they can put that in
> the subject line.  However, I don't think a bug id can be assigned via email,
> that is, I think you have to use a web form to create a bug report with a bug
> id.  Presumably that could change if whoever runs the bug counter wants it to.

Yeah, fixing this would probably be tied to the possible change to
mailman.  Unless someone already has a way to get majordomo to append a
bug ID.

> 5: How can we use email to update the status of a bug?
> 
> I suggest using email headers to do this.  'X-PGBug-Fixed: <commitid>' and the
> like.  I assume here that everyone who might want to do such a thing uses an
> MUA that would allow this, and they know how.

I guess that depends on who we expect to use this, at least for closing
stuff.

> 6: Does there need to be any security on updating the status?
> 
> Probably not.  I don't think it's the sort of thing that would attract
> malicious adjustments.  If I'm wrong, I'd need to rethink this.  I realize I'm
> making security an afterthought, which makes my teeth itch, but I think layers
> of security would make it much less likely to be actually adopted.

I think there needs to be some kind of administrative access which
allows, for example, an issue to be closed so that it can't be reopened.

Anyway, I'm not convinced we want to reinvent this particular wheel, but
if we do, you've done a yeoman's job.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com