bugs and bug tracking

Nathan,

* Nathan Wagner (nw+pg@hydaspes.if.org) wrote:

So, in order to do some clean up and see how my pgbugs page
(https://granicus.if.org/pgbugs/) might actually work I've been going
through bugs and marking their status. A lot of questions arise.

Thanks for working on this!

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.

While I agree with you that they are requests for help, I doubt changing
the submission form would really help much.

[...]

I have lots of different types of 'not a bug'.

debbugs has categories for more-or-less all of these:

For the case where it's a feature rather than a bug, there's "wishlist".

Not a bug, the use should have posted to a different list. (e.g. 13602)
Not a bug, probably user error, which is similar to the above.
Not a bug, but a bug in the libraries we use (e.g. openssl, 10184)

The ones above would all simply be closed with a comment to the user
about what the issue is.

Not a bug, works as intended, i.e. the user didn't make a mistake, but
had an incorrect notion of what it was supposed to do. (11596)

This could be either closed or, if it pops up enough, left as 'wontfix',
so other users don't report it again.

Not a bug, but the user never got a reply. That is, I decided
personally that this wasn't actually a bug. (13367)

One thing with debbugs, at least, is that the user gets an initial reply
saying "we got it" and then another whenever the status changes
(including if it gets closed out as not-a-bug or similar).

And bug 1000 is not a bug, system test.

Eh, not sure we need to worry about that one too much. :)

Do we care about the difference between any of these? I track them
differently in my update script, but they all get the same status in the
db.

I like the set of categories which debbugs provides.

Can a bug be 'fixed' if there's no actually identifiable commit that
fixes the bug? See 13516, which Tom Lane claims was fixed in 9.1. A
grep for 13516 of the git log for both master and REL9_1_STABLE don't
turn up anything.

Yes, that can certainly happen. It'd be better if the commit which
actually fixed it was found but that's just being idealistic- whatever
we use shouldn't force us to close a bug with a commit (debbugs
certainly doesn't).

I can't as yet figure out how to match up git commit messages to
identify every branch in which a fix was applied. I could of course
load all of the commit messages into a table and compare them that way.

Can't this be done by simply looking for the bug# in the commit log for
each branch and, when found, associating that branch with the bug#?

Should I mark as "open" (i.e. not "new) any report that has a response?
More than one response? That would at least distinguish between bug
reports that at least someone, in theory, has taken a look at, and those
that haven't been addressed at all.

I'm not sure that distinction is particularly useful, but I know some
systems do it.

I have created the following statuses:

Fixed - bug is presumably fixed

Ok.

Unreproduceable - we can't make the system demonstrate this error

This should be a flag or attribute of the bug, not a final disposition.

Timed Out - the reporter was asked to provide more information and
didn't respond for a while. I would probably suggest somewhere around a
month for this. Should there be a 'waiting on feedback' to mark the
'pre timed out' phase?

Not sure we need this, isn't it just 'closed'?

Stale 5281 - the bug hasn't had any activity for >2 years, so just
close it. If people want to troll through these to give them a better
status, that would probably be good, but there's still a thousand open
bugs newer than that.

How is this different from 'timed out'?

Not Our Bug - looks like a bug, but it's not a bug in postgres. What
exactly are our bugs? Just what you'd get out of the release tarballs
or the git repo? Or is there more?

This would also be 'closed', but with a note saying it's not our issue.

Won't Fix - this is arguably a bug, but for some reason we're not going
to fix it. Perhaps we intentionally violate the standard, or it's a bug
against a version we don't support, or we're not going to backpatch it.

I'm not sure that it's actually a bug, it's more of a placeholder that
says "yes, we understand people might think this behavior should be
different, but we don't agree and aren't going to change it."

Open - this seems to be a bug, or at least we're talking about it and
it's not where we want to close it. Note of course that "closing" a bug
just means it will show up somewhere else in my tracker, obviously it
doesn't affect the mailing list at all.

Yes, closed bugs should still be available for review.

New - this hasn't been looked at enough for someone to change the status
to something better.

Alright.

We should also have 'wishlist', imv, as discussed.

I don't have a "reopened" status. I'm not sure what it means, other
than it used to be closed, but someone changed it back to open. I don't
immediately see why we would want to distinguish between this and a
regular open bug, other than perhaps as a way of conflating status with
priority. It's easy to make one though if people really want it. I
probably have too many statuses already.

I think we want to track that it was closed and then opened again but I
don't think it needs a formal status. Generally speaking, we should be
tracking all actions against a given bug (as debbugs does).

I will post later on my thoughts on how to control the system. Are
people, in principle, willing to put magic incantations in their emails
and commit messages? I'm not asking for a commitment to my tool here,
I'm just exploring what the bounds of people's, and committer's in
particular, willingness to adjust their workflow or message texts a bit
to make it easier to automate bug tracking. Even if people don't
want to use what I've done, the same problems arise for any system.

'magic incantations' are probably alright, up to a point- they generally
shouldn't be required for messages to be added to the bug.

The biggest issue that I see with building a new system like this rather
than using something which already exists is that dealing with email is
no trivial task, as we've seen with our archives system and with the
various other bug trackers that have been discussed (many of which don't
deal very well with email).

Thanks!

Stephen

On 6 October 2015 at 08:05, Nathan Wagner <nw+pg@hydaspes.if.org> wrote:

So, in order to do some clean up and see how my pgbugs page
(https://granicus.if.org/pgbugs/) might actually work I've been going
through bugs and marking their status. A lot of questions arise.

/***** DISCLAIMER *****/

My opinion is not important in this issue

/***** END DISCLAIMER *****/

I like how this page is looking now, good work.
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:
/messages/by-id/E1ZfJGX-0005lu-UQ@gemulon.postgresql.org).
is it possible (even if not yet implemented) to add that information?

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.

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.

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.

--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Oct 6, 2015 at 7:04 PM, Jaime Casanova <
jaime.casanova@2ndquadrant.com> wrote:

On 6 October 2015 at 08:05, Nathan Wagner <nw+pg@hydaspes.if.org> wrote:

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.

It doesn't actually. You can post to the bugs list without being subscribed
and it hits moderation. If you fill out the bug form without being
subscribed, it hits exactly the same moderation. There is no difference -
the bug form basically just sends an email with your address as the from
one.

It might be that we don't make that clear, but that's how it works :)

Maybe we need a "question" form thta does the same thing but doesn't assign
a bugid and just sends an email to -general instead?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus@hagander.net> writes:

It doesn't actually. You can post to the bugs list without being subscribed
and it hits moderation. If you fill out the bug form without being
subscribed, it hits exactly the same moderation. There is no difference -
the bug form basically just sends an email with your address as the from
one.

It might be that we don't make that clear, but that's how it works :)

Maybe we need a "question" form thta does the same thing but doesn't assign
a bugid and just sends an email to -general instead?

Seems like a good idea, but if you make it a separate form, lots of people
will never see it. How about having just one page, but a drop-down menu
for "bug" versus "question"?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Oct 6, 2015 at 01:05:24PM +0000, Nathan Wagner wrote:

So, in order to do some clean up and see how my pgbugs page
(https://granicus.if.org/pgbugs/) might actually work I've been going
through bugs and marking their status. A lot of questions arise.

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 explanation on the submission
form would be useful.

I am glad you are putting together a mock-up solution with actual data
so we can see what a final solution would look like, and see some of the
decisions we have to make.

First, let me say I am glad we are talking about this, and am open to
the criticism that my and other's tracking open items by keeping them in
our personal mailboxes is not only odd, but bizarre given the size of
our community and the responsibility we have.

I do think we rushed to choose a tracker a little too quickly. Let me
explain, from a high level, what a new tracker will change in our
workflow. Right now, items stream at us via email. They are broadcast
to everyone on the lists. For most people, the email just flies by and
is deleted. For a few people, they respond, and generate more activity.
For a few others, they keep the email to see if is resolved, and if not,
try to get it resolved later, or recorded.

Therefore, our current default behavior is to ignore user reports,
unless someone takes an action to reply, record, or retain the email for
later review. What a tracker does is to make the default user report be
_retained_, meaning we have to take action to _not_ retain a user report
as an open item.

This gets to the core issue --- that maintaining a tracker is going to
require more work than what we do now, and explains why most community
project trackers (and perhaps most commercial project trackers) become
clogged with unaddressed items. This also highlights the need for a
serious dedication of time to keep a tracker orderly. This is perhaps
best expressed by this comment from Andrew Dunstan:

/messages/by-id/560D4960.5010401@dunslane.net

In my former life I once had to send out a memo to developers
that said "If you're not working on items in the tracker you're
not doing your job."

In summary, a tracker can become an unrelenting task-master, where you
are continually un-retaining items and reclassifying, which might
explain why they often end up disorderly or ignored. There are
advantages to having a tracker, but it will take action on our part to
manage the new default-retain behavior. I think this is why email
integration is key, because it allows us to adjust the retain behavior
with minimal effort.

Second, we have a mix of user reports. Some bug reports are not bugs
and must be reclassified. In other cases, uses ask questions via
non-tracked communicate channels, e.g. pgsql-general, but they are
really bugs. So, to do this right, we need a way of marking tracked
bugs as not bugs, and a way of adding bugs that were reported in a
non-tracked manner.

One of the advantages of the non-retain behavior we have now is that,
for responsible developers, a recognized bug either has to be recorded
or fixed --- both take time, so we have a tendency to choose "fix".
With a retain-default behavior, "recorded" becomes the default and the
pressure to fix is reduced. Of course, there is also the "let it fly by
and ignore it option", which we have now, and which we will not have in
the default-retain mode.

My point is that we have our current workflow not because we are idiots,
but because it fit our workflow and resources best. I am not sure if we
have succeeded because of our current non-retain mode, or in spite of
it. It might be time to switch to a default-retain mode, especially
since most other projects have that mode, but we should be clear what we
are getting into.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription                             +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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:
/messages/by-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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/06/2015 10:17 AM, Bruce Momjian wrote:

First, let me say I am glad we are talking about this, and am open to
the criticism that my and other's tracking open items by keeping them in
our personal mailboxes is not only odd, but bizarre given the size of
our community and the responsibility we have.

On the other hand, until we do have some kind of tracker, it is
absolutely essential. But at this point, it's more than one person can do.

This is kind of like CVS. We didn't upgrade so Subversion, becuase we
said "we already have a user-friendly interface to CVS, called Marc."
We only moved to git when it could provide us with solid advantages.

I believe the same thing is happening here. The inefficiency of the old
system (Bruce's mailbox) is becoming higher than the inefficiency of a
new, hypothetical system.

Therefore, our current default behavior is to ignore user reports,
unless someone takes an action to reply, record, or retain the email for
later review. What a tracker does is to make the default user report be
_retained_, meaning we have to take action to _not_ retain a user report
as an open item.

Well, we can determine how that's handled. There are bug trackers out
there that automatically archive unconfirmed bug reports after a certain
amount of time. I'd personally recommend it.

Of course, that requires a bug tracker which can have an "unconfirmed"
status.

Second, we have a mix of user reports. Some bug reports are not bugs
and must be reclassified. In other cases, uses ask questions via
non-tracked communicate channels, e.g. pgsql-general, but they are
really bugs. So, to do this right, we need a way of marking tracked
bugs as not bugs, and a way of adding bugs that were reported in a
non-tracked manner.

Yeah, I was wondering about that.

My point is that we have our current workflow not because we are idiots,
but because it fit our workflow and resources best. I am not sure if we
have succeeded because of our current non-retain mode, or in spite of
it. It might be time to switch to a default-retain mode, especially
since most other projects have that mode, but we should be clear what we
are getting into.

FWIW, when I talk about bugs which we lost track of, they're not
generally unconfirmed bug reports. Usually, it's stuff which a
contributor replied to, but the bug was low-impact, circumstantial, and
hard to reproduce, and came in during a busy period (like release time).
So I'd be perfectly OK with the idea that unconfirmed bugs hang around
in the system for 60 days, then automatically convert to "stale" status.
Until we build up a team of volunteers for bug triage, we might have to
do that.

Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community supporters can do, if we make it
easy for them to do.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Oct 06, 2015 at 10:57:42AM -0700, Josh Berkus wrote:

On 10/06/2015 10:17 AM, Bruce Momjian wrote:

Therefore, our current default behavior is to ignore user reports,
unless someone takes an action to reply, record, or retain the email for
later review. What a tracker does is to make the default user report be
_retained_, meaning we have to take action to _not_ retain a user report
as an open item.

Well, we can determine how that's handled. There are bug trackers out
there that automatically archive unconfirmed bug reports after a certain
amount of time. I'd personally recommend it.

Of course, that requires a bug tracker which can have an "unconfirmed"
status.

This is essentially what I have done with the 'Stale' status. Though
I have done at two years to be conservative, rather than 60 days,
which I think is entirely more reasonable.

Second, we have a mix of user reports. Some bug reports are not bugs
and must be reclassified. In other cases, uses ask questions via
non-tracked communicate channels, e.g. pgsql-general, but they are
really bugs. So, to do this right, we need a way of marking tracked
bugs as not bugs, and a way of adding bugs that were reported in a
non-tracked manner.

Yeah, I was wondering about that.

I think I have suggested that there be a way to generate a bug id via
email. Presumably someone could just copy that email address to make a
not-tracked discussion get a bug id. If the system archived all the
lists (not hard) it would be possible to pull the other emails from the
thread into the bug (also not hard). As for marking as 'not-a-bug'
this can easily be done via whatever mechanism might be used.
Something along the lines of:

Bug Status: not a bug

would probably work. It's really whatever people are willing to
actually do.

FWIW, when I talk about bugs which we lost track of, they're not
generally unconfirmed bug reports. Usually, it's stuff which a
contributor replied to, but the bug was low-impact, circumstantial, and
hard to reproduce, and came in during a busy period (like release time).
So I'd be perfectly OK with the idea that unconfirmed bugs hang around
in the system for 60 days, then automatically convert to "stale" status.

My tracker would do this trivially if I changed the query to 60 days
instead of two years.

Until we build up a team of volunteers for bug triage, we might have to
do that.

Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community supporters can do, if we make it
easy for them to do.

I can make it easy. But that doesn't directly address two of the other
points:

1: Do we need any system for who is allowed to triage bugs?
2: Should an equivalent email be sent to the list?

Specifically with point number 2, suppose the above mechanism is
used. When a triager marks a bug as (say) not a bug, should
the system just update the database, or should it actually
send a formatted email to the bugs list with the 'Bug Status: not a bug'
line (among others, presumably)? I think it should send the email,
but I can see how that could be construed as junk.

--
nw

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/06/2015 10:57 AM, Josh Berkus wrote:

On 10/06/2015 10:17 AM, Bruce Momjian wrote:

This is kind of like CVS. We didn't upgrade so Subversion, becuase we
said "we already have a user-friendly interface to CVS, called Marc."
We only moved to git when it could provide us with solid advantages.

This is a very good point.

I believe the same thing is happening here. The inefficiency of the old
system (Bruce's mailbox) is becoming higher than the inefficiency of a
new, hypothetical system.

As one of the longest running contributors to this community, I didn't
even know that is where bugs went. How I didn't know this, I have no idea :P

Second, we have a mix of user reports. Some bug reports are not bugs
and must be reclassified. In other cases, uses ask questions via
non-tracked communicate channels, e.g. pgsql-general, but they are
really bugs. So, to do this right, we need a way of marking tracked
bugs as not bugs, and a way of adding bugs that were reported in a
non-tracked manner.

Yeah, I was wondering about that.

Right, that is why I am trying to push us toward an "issue" tracker not
a bug tracker. A bug tracker explicitly limits the purpose of something
that may otherwise be a huge boon to this community.

Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community supporters can do, if we make it
easy for them to do.

That is an understatement. There is a huge pool of non-hackers that can
help contribute to this sort of thing.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
New rule for social situations: "If you think to yourself not even
JD would say this..." Stop and shut your mouth. It's going to be bad.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 6 October 2015 at 12:32, Nathan Wagner <nw+pg@hydaspes.if.org> wrote:

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.

i also don't agree that everything will happen by magic...

for example, bug # 6150 (https://granicus.if.org/pgbugs/6150) was
reported for PostgreSQL version: 0.9
so we need a way to, at least, fix those.

also, while the bug report allow you to say which OS was affected that
is the one the user was using. still the bug could happen in all OSes
(versions?), only some, only a specifi OS in a specific version is
affected.

so we need, to have an interface to fix metada... and people taking
responsability for that

--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Oct 6, 2015 at 8:15 PM, Nathan Wagner <nw+pg@hydaspes.if.org> wrote:

On Tue, Oct 06, 2015 at 10:57:42AM -0700, Josh Berkus wrote:

Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community supporters can do, if we make it
easy for them to do.

I can make it easy. But that doesn't directly address two of the other
points:

1: Do we need any system for who is allowed to triage bugs?
2: Should an equivalent email be sent to the list?

Specifically with point number 2, suppose the above mechanism is
used. When a triager marks a bug as (say) not a bug, should
the system just update the database, or should it actually
send a formatted email to the bugs list with the 'Bug Status: not a bug'
line (among others, presumably)? I think it should send the email,
but I can see how that could be construed as junk.

I think that's an absolute requirement. Otherwise the system will force
people to check both email and the tracker. The whole point is that those
who prefer the email-only workflow should be able to keep that one.

If someone doesn't want them, it's easy enough to filter them in the MUA.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Tue, Oct 6, 2015 at 10:57:42AM -0700, Josh Berkus wrote:

This is kind of like CVS. We didn't upgrade so Subversion, becuase we
said "we already have a user-friendly interface to CVS, called Marc."
We only moved to git when it could provide us with solid advantages.

I believe the same thing is happening here. The inefficiency of the old
system (Bruce's mailbox) is becoming higher than the inefficiency of a
new, hypothetical system.

Yes, just like I used to handle the uncommitted patches until we had a
commitfest app. I was glad to be done with that job too.

Therefore, our current default behavior is to ignore user reports,
unless someone takes an action to reply, record, or retain the email for
later review. What a tracker does is to make the default user report be
_retained_, meaning we have to take action to _not_ retain a user report
as an open item.

Well, we can determine how that's handled. There are bug trackers out
there that automatically archive unconfirmed bug reports after a certain
amount of time. I'd personally recommend it.

Of course, that requires a bug tracker which can have an "unconfirmed"
status.

Yes, interesting idea. Basically, someone needs to get more benefit
from the tracking than the work we put into it. It might be that our
users mostly get the benefits.

Second, we have a mix of user reports. Some bug reports are not bugs
and must be reclassified. In other cases, uses ask questions via
non-tracked communicate channels, e.g. pgsql-general, but they are
really bugs. So, to do this right, we need a way of marking tracked
bugs as not bugs, and a way of adding bugs that were reported in a
non-tracked manner.

Yeah, I was wondering about that.

Yes, that is 50% of the items that end up on the TODO list.

Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community supporters can do, if we make it
easy for them to do.

Yes. Part of the problem is that tracker maintenance is almost done in
a closet, so there is little outward reinforcement to keep people
motivated.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription                             +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Joshua D. Drake wrote:

On 10/06/2015 10:57 AM, Josh Berkus wrote:

On 10/06/2015 10:17 AM, Bruce Momjian wrote:

Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community supporters can do, if we make it
easy for them to do.

That is an understatement. There is a huge pool of non-hackers that can
help contribute to this sort of thing.

It was said, way back when, "adding Windows support will add a huge pool
of Windows-only developers". I'm not sure that the impact was really
all that big there. We have a few Windows-enabled people, but how many
of them are Windows-only?

We similarly said, "moving the TODO list to the wiki will add a huge
pool of users that cannot edit the current CVS-only file". To date,
most of what has happened is that the old items have become stale and
Bruce continues to do 99% of the work of maintaining it.

So I am dubious that people that currently do not contribute will
contribute in the future just because we change the system.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Oct 06, 2015 at 01:17:48PM -0400, Bruce Momjian wrote:

I do think we rushed to choose a tracker a little too quickly.

Have we chosen one?

Let me explain, from a high level, what a new tracker will change in
our workflow.

[snip]

I won't quote your whole message, which I essentially agree with. Let
me say that the questions I have brought up have several purposes.

One, I think it's important to identify what exactly we're after. I
hope my questions have help put some light on that.

Two, I think any attempt to tell the developers and committers that they
need to change their workflow to adapt to some system is bound to fail,
so, I have asked, just what changed would you all be willing to actually
*do*? Tom Lane is pretty good at noting a bug number in his commit
messages, for example. Would he be willing to modify that slightly to
make it easier to machine parse? Would you be willing to add a bug
number to your commit messages? I'm not asking for guarantees.
Actually I'm not really asking for anything, I'm just trying to figure
out what the parameters of a solution might be. If the answer to that
is "no, I'm not willing to change anything at all", that's fine, it just
colors what might be done and how much automation I or someone else
might be able to write.

I think even with a bug tracker the default "ignore" behavior can still
be done. In principle, we could even mark bugs as "unconfirmed" or
"logged" or something right away and only mark them as new or open or
something if they actually draw a reply. We could even require a reply
from a committer if that was wanted.

If I haven't made it clear by now, I am trying to write a system that
requires the absolute minimal amount of change to the existing way of
doing things. As I noted in my original email, I've put together a bug
tracker, not a ticket system. If people would like to make some small
adjustments to make it easier to automate a bug tracker, that would be
great, but if not, that's fine too, it's no *worse* than what we already
have. And if people really wanted a ticket system, it wouldn't be hard
to enhance a tracker.

My point is that we have our current workflow not because we are
idiots, but because it fit our workflow and resources best. I am not
sure if we have succeeded because of our current non-retain mode, or
in spite of it. It might be time to switch to a default-retain mode,
especially since most other projects have that mode, but we should be
clear what we are getting into.

I thinking having a bug tracker and retention vs non-retention are
orthogonal questions. But I agree that knowing what might be involved
is a good idea. I think perhaps one of the problems is that different
people want different things, so it's probably going to be hard to make
everyone happy.

--
nw

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/06/2015 11:33 AM, Alvaro Herrera wrote:

Joshua D. Drake wrote:

On 10/06/2015 10:57 AM, Josh Berkus wrote:

On 10/06/2015 10:17 AM, Bruce Momjian wrote:

Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community supporters can do, if we make it
easy for them to do.

That is an understatement. There is a huge pool of non-hackers that can
help contribute to this sort of thing.

It was said, way back when, "adding Windows support will add a huge pool
of Windows-only developers". I'm not sure that the impact was really
all that big there. We have a few Windows-enabled people, but how many
of them are Windows-only?

I think it was naive that anyone would suggest that windows developers
would show up, we aren't friendly to them. It is true that we go through
great pains to have a decent Windows port but our community is and
(AFAICT) forever will be, Unix centric.

We similarly said, "moving the TODO list to the wiki will add a huge
pool of users that cannot edit the current CVS-only file". To date,
most of what has happened is that the old items have become stale and
Bruce continues to do 99% of the work of maintaining it.

That isn't a wiki issue it is a lack of policy issue. How do we define
what becomes a TODO? How can someone submit a TODO? Does it get voted
on? Where is this documented? (list goes on)

So I am dubious that people that currently do not contribute will
contribute in the future just because we change the system.

No, not just because we change the software. The mindset has to change
too and procedures have to change too.

That said, your argument boils down to, "I once heated water with wood
and it didn't boil. Therefore I won't heat water again."

It should be, "I once heated water with wood and it didn't boil. How can
I change my process so that it will?"

Until hackers have that mindset about all this stuff (except hacking) we
will continue to hit walls we don't have to hit.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
New rule for social situations: "If you think to yourself not even
JD would say this..." Stop and shut your mouth. It's going to be bad.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Joshua D. Drake wrote:

On 10/06/2015 11:33 AM, Alvaro Herrera wrote:

So I am dubious that people that currently do not contribute will
contribute in the future just because we change the system.

No, not just because we change the software. The mindset has to change too
and procedures have to change too.

That said, your argument boils down to, "I once heated water with wood and
it didn't boil. Therefore I won't heat water again."

[I have heated water with wood till boiling point, FWIW]

It should be, "I once heated water with wood and it didn't boil. How can I
change my process so that it will?"

Oh, I am not saying we shouldn't have a tracker ("change the process").
I'm just saying that this particular argument for it is bogus.

Until hackers have that mindset about all this stuff (except hacking) we
will continue to hit walls we don't have to hit.

I personally deal with bug reports almost every day and would love to
see a change in this area. I am not hopeful that unwashed masses will
jump to assist me (us) in keeping the bug tracker clean and useful.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/06/2015 11:51 AM, Alvaro Herrera wrote:

Joshua D. Drake wrote:

[I have heated water with wood till boiling point, FWIW]

Hahahah I have no doubt.

It should be, "I once heated water with wood and it didn't boil. How can I
change my process so that it will?"

Oh, I am not saying we shouldn't have a tracker ("change the process").
I'm just saying that this particular argument for it is bogus.

Until hackers have that mindset about all this stuff (except hacking) we
will continue to hit walls we don't have to hit.

I personally deal with bug reports almost every day and would love to
see a change in this area. I am not hopeful that unwashed masses will
jump to assist me (us) in keeping the bug tracker clean and useful.

I don't think the unwashed masses will either but I bet we could get a
handful from -general and even a few that watch but don't participate on
this list.

Frankly, I bet the next time I speak I could get at least one volunteer
just by bringing it up (how do you think this whole bug tracker thing
started?).

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
New rule for social situations: "If you think to yourself not even
JD would say this..." Stop and shut your mouth. It's going to be bad.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Oct 6, 2015 at 03:33:20PM -0300, Alvaro Herrera wrote:

Joshua D. Drake wrote:

On 10/06/2015 10:57 AM, Josh Berkus wrote:

On 10/06/2015 10:17 AM, Bruce Momjian wrote:

Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community supporters can do, if we make it
easy for them to do.

That is an understatement. There is a huge pool of non-hackers that can
help contribute to this sort of thing.

It was said, way back when, "adding Windows support will add a huge pool
of Windows-only developers". I'm not sure that the impact was really
all that big there. We have a few Windows-enabled people, but how many
of them are Windows-only?

We similarly said, "moving the TODO list to the wiki will add a huge
pool of users that cannot edit the current CVS-only file". To date,
most of what has happened is that the old items have become stale and
Bruce continues to do 99% of the work of maintaining it.

So I am dubious that people that currently do not contribute will
contribute in the future just because we change the system.

Agreed, though that did work for the commitfest --- I almost never deal
with those patches, for good and bad.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription                             +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/06/2015 12:03 PM, Bruce Momjian wrote:

On Tue, Oct 6, 2015 at 03:33:20PM -0300, Alvaro Herrera wrote:

Joshua D. Drake wrote:

On 10/06/2015 10:57 AM, Josh Berkus wrote:

On 10/06/2015 10:17 AM, Bruce Momjian wrote:

Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community supporters can do, if we make it
easy for them to do.

That is an understatement. There is a huge pool of non-hackers that can
help contribute to this sort of thing.

It was said, way back when, "adding Windows support will add a huge pool
of Windows-only developers". I'm not sure that the impact was really
all that big there. We have a few Windows-enabled people, but how many
of them are Windows-only?

We similarly said, "moving the TODO list to the wiki will add a huge
pool of users that cannot edit the current CVS-only file". To date,
most of what has happened is that the old items have become stale and
Bruce continues to do 99% of the work of maintaining it.

So I am dubious that people that currently do not contribute will
contribute in the future just because we change the system.

Agreed, though that did work for the commitfest --- I almost never deal
with those patches, for good and bad.

There isn't a huge pool, but then we don't need a huge pool. We need
like three people, and I think that's not unreasonable to expect.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers