Re: bugs and bug tracking - Mailing list pgsql-hackers

From Nathan Wagner
Subject Re: bugs and bug tracking
Date
Msg-id 20151006173243.GA320@granicus.if.org
Whole thread Raw
In response to Re: bugs and bug tracking  (Jaime Casanova <jaime.casanova@2ndquadrant.com>)
Responses Re: bugs and bug tracking  (Jaime Casanova <jaime.casanova@2ndquadrant.com>)
List pgsql-hackers
On Tue, Oct 06, 2015 at 12:04:11PM -0500, Jaime Casanova wrote:

> I like how this page is looking now, good work.

Thank you.

> Now, AFAIU from previous mails part of the reason to have a bug
> tracker is to make easy to know when a bug was fixed. Which should be
> interpreted as: which versions this bug affected? and which minor
> versions on those branches fix the issue
> 
> for example bug # 13636 was reported for 9.4.4 but it existed in older
> branches so Tom fixed it in all active branches (ie:
> http://www.postgresql.org/message-id/E1ZfJGX-0005lu-UQ@gemulon.postgresql.org).
> is it possible (even if not yet implemented) to add that information?

It is possible.  I don't know yet how easy it will be to automate it for
all the back patches.  I think I can look for matching commit messages
but I haven't written any code yet.  It might be possible to infer
this information after the fact by looking at where on which branches
a commit fix was applied.

> also i like that we can search on bugs but we can filter by version.
> i'm just guessing that if someone looks for a bug he's probably
> worrying about the specific version he is using.

I'll probably get to adding filtering soon-ish.  Maybe even today.  I
haven't decided if I want to do that on the server side, or add some
javascript to let the user sort and filter whatever the page has already
returned.  I'm not really a web guy, so it takes me a while to figure
out what to do.

> having a bug tracker that allow us to not lose track of bugs is good,
> having a bug tracker that allow us to have the whole information on a
> bug is better, IMHO.

I agree.  It's just a matter of somehow automating the process.  I'm
under no illusions though that I have any control over things.  I'm
hoping that one or more of the committers will say "we'd like to do it
this way" and I'll work with that.  Personally, I'd like to see either
'[Fixes #12345]' anywhere in a commit message, or 'Fixes: #12345' at the
beginning of a line.  But it has to come from them.

Also, the version numbers are user reported and a bit of a mess.  I
don't think they could really be relied on as is for users trying to
find out if a bug affects their version.  Someone would have to update
that information, and communicate that update to the tracker.  The
general concensus seems to be that magic phrases at the beginning of a
line in a message body is the way to go.  I don't necessarily agree, but
any consistent system can be made to work.  This obviously applies to
any metadata, not just version numbers.

> > A lot of the reports aren't bugs at all, but requests for help.  My
> > guess is that the users either don't know where to ask or don't
> > understand the difference between a bug and not knowing how to do what
> > they want to do.  Perhaps a more thorough explaination on the submission
> > form would be useful.
> >
> 
> the real problem here is that fill the bug report doesn't force you to
> register in a ML, while asking for help in a ML will. and a lot of
> people don't want to register in a ML, they just want a specific
> question answered so i don't think any change in the form will avoid
> that.

True.  Perhaps we could provide another form for other lists.  Probably
tilting at windmills here, but it would be nice if we could cut down
on the amount of time taken up by "this isn't a bug, you should go ask
down the hall".

-- 
nw



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: bugs and bug tracking
Next
From: Josh Berkus
Date:
Subject: Re: bugs and bug tracking