Thread: bugs and bug tracking

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

What is the difference between a bug and a feature request?  Ok, I know
the difference, but do we want to treat them differently.  For example,
see bug 9457 (https://granicus.if.org/pgbugs/9457).  As Pavel Stehule
noted, this isn't a *bug* per se, but what should we do with it?  Close
it as 'not a bug'?  I don't like this because it's not really the same
as the other 'not a bug's.  Create another 'closed' status of 'feature
request'?  Except that if we decide to implement the feature, in some
sense it becomes a bug until we actually implement it.  Create an 'open'
status of 'feature request' to mark it until it is either implemented or
rejected.  At least then it's tracked.  This last choice is my
preference.

I conflate open bugs in the sense of 'not closed so we still need to do
something with the bug even if it is just closing it' and open bugs in
the sense of 'this seems to actually be a bug in postgres'.  I'm not
sure what terminology I should use.

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

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)
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)
Not a bug, but the user never got a reply.  That is, I decided
personally that this wasn't actually a bug.  (13367)
And bug 1000 is not a bug, system test.

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.

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.

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.

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 have created the following statuses:

Fixed - bug is presumably fixed

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

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?

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.

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?

Not a Bug - see above discussion

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.

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.

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

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 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.

-- 
nw

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:
http://www.postgresql.org/message-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

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

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:
http://www.postgresql.org/message-id/560D4960.5010401@dunslane.netIn my former life I once had to send out a memo to
developersthatsaid "If you're not working on items in the tracker you'renot 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                             +

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

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
unconfirmedbugs 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

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

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.

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

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                             +

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

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

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.

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

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.

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                             +

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

On 6 October 2015 at 21: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.

Based on experience elsewhere, not even "unless you are absolutely
certain this is a bug, post to pgsql-general" would work.

Unless there's a "post to pgsql-general" text box right there,
forum-like. Because that's the point IMO: it's easier to post to a web
form than think about mailing lists and subscriptions. You can't just
go "click, send". People are going to consistently ignore the fact
that it's a bug report form when there's no corresponding "ask a
question" web form.

I'm not really advocating a "send a question" web form though. More
like a link to Stack Overflow or something like that.


-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

On 7 October 2015 at 02:33, Nathan Wagner <nw+pg@hydaspes.if.org> wrote:

> 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.

IMO it'd need to be a reply with a keyword or something, because if
you look at the bug history, a whole lot of bugs get replies of "what
version is this anyway? And what exact steps did you take?". Then
trail off as the submitter doesn't respond, or sends more
unintelligible gibberish.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

* Nathan Wagner (nw+pg@hydaspes.if.org) wrote:
> 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

If we're providing control messages through email (which I absolutely
believe needs to be supported), I'd strongly prefer that they be easy to
write.  The above isn't.

A good set of commands to support can be seen here:

https://www.debian.org/Bugs/server-control

The way debbugs currently works, which I like, is that you email
NNNN-done@bugs.debian.org (NNNN being the bug #) and that automatically
closes the bug and that email is sent to the bug reporter.  Generally,
this will be in a reply to an email which came from, or at least CC'd,
NNNN@bugs.debian.org, so changing the address to go to -done is quite
easy.

An example would go something like:

Initial email:

-----------
From: 1234@bugs.postgresql.org
[...]
PG should do X
-----------

Reply email:

-----------
From: sfrost@snowman.net
To: 1234-done@bugs.postgresql.org, control@bugs.postgresql.org

tag 1234 wontfix
thanks

Blah, blah, this is why we don't consider this a bug
-----------

Currently with debbugs (afaik, I can double-check with Don though), to
actually add tags you have to email control@, which will read and
process commands up until it finds a "thanks" or similar end-command.
Since the email is going to control@, you have to specify which bug
you're adding the tag to.

Here's an example of how the system is used:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=100132

Using control@, etc, avoids having to figure out if a given email sent
to NNN@bugs.postgresq.org has commands in it or not (all emails to
control@ are assumed to have commands).

Thanks!

Stephen

Magnus,

* Magnus Hagander (magnus@hagander.net) wrote:
> On Wed, Oct 7, 2015 at 4:40 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Nathan Wagner (nw+pg@hydaspes.if.org) wrote:
> > > 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
> >
> > If we're providing control messages through email (which I absolutely
> > believe needs to be supported), I'd strongly prefer that they be easy to
> > write.  The above isn't.
> >
> > A good set of commands to support can be seen here:
> >
> > https://www.debian.org/Bugs/server-control
> >
> > The way debbugs currently works, which I like, is that you email
> > NNNN-done@bugs.debian.org (NNNN being the bug #) and that automatically
> > closes the bug and that email is sent to the bug reporter.  Generally,
> > this will be in a reply to an email which came from, or at least CC'd,
> > NNNN@bugs.debian.org, so changing the address to go to -done is quite
> > easy.
>
>
> If I understand that correct, it completely breaks the current workflow of
> "reply-all"? When I need to comment on a bug, isntead of hitting reply-all,
> i should send it to the @bugs address? Or are you saying in those cases you
> still hit reply-all but just edit the actual address?

This, imv anyway, is why I need to just set it up and show people how it
works.

reply-all works just fine, since you like to know *exactly* how it works
at a technical level, I just checked and the bug email address is
automatically included in the Reply-To: header rather than being CC'd
or From.  The bug submitter's email is also in the Reply-To.

Please understand that, at least in my experience, Debian's workflows
are *very* similar to ours.  They just hammered out these questions
about how to make it work over the past 15 years that we've been writing
a database. ;)

> (FWIW, I think editing the actual address is nowhere near as easy as just
> adding a Status: <whatever> to the message itself. It's likely easier to
> deal with on the *server* side, but it's definitely not easier for the
> user. Especially if you're in a MUA that doesn't let you easily edit a mail
> address (hello gmail! which is quite a few of our users..)

An email to control@ with

close 1234

*is* also supported, but the Debian folks prefer using -done since the
email to -done always goes to the submitter, whereas using 'close 1234'
means you have to make sure you also email the submitter.  That's
certainly possible, but if you weren't on the bug originally for
whatever reason then you have to go get the submitter's email address,
etc.

My MUA makes changing an email To: line really easy and since I'm one of
the users of that part of the system, I like it.

One thing that's important to understand is that this system (in
particular, the email interface) is *not* for our users (more
specifically, it's not for the individuals who submit bugs via the bug
form).

It's for *us*.

Thanks!

Stephen

Magnus Hagander <magnus@hagander.net> writes:
> If I understand that correct, it completely breaks the current workflow of
> "reply-all"? When I need to comment on a bug, isntead of hitting reply-all,
> i should send it to the @bugs address? Or are you saying in those cases you
> still hit reply-all but just edit the actual address?

> (FWIW, I think editing the actual address is nowhere near as easy as just
> adding a Status: <whatever> to the message itself. It's likely easier to
> deal with on the *server* side, but it's definitely not easier for the
> user. Especially if you're in a MUA that doesn't let you easily edit a mail
> address (hello gmail! which is quite a few of our users..)

FWIW, I agree that encoding this sort of thing in the email address seems
like a pretty bad idea, because other people might reply-all to the
modified address.  Consider this flow:
bug submittedinsufficiently-thought-through reply to NNNN-done with "not a bug"submitter replies (with cc to NNNN-done)
withmore detailsreply: oh, you're right, so we should reopen it
 

At least half, if not all, of the subsequent traffic in the thread is
going to get cc'd to NNNN-done, thus repeatedly causing the bug to get
"closed" prematurely.

If you want such an API, I won't stop you from using it, but I will not
use it myself.  Please put in message-body commands as well.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> If you want such an API, I won't stop you from using it, but I will not
> use it myself.  Please put in message-body commands as well.

So, unsurprisingly, debbugs does support all commands that can be sent
to control@ also through the NNN@bugs.postgresql.org system; the command
simply needs to be prefixed with 'Control: ' and then '-1' can be used
as the bug number (so you don't have to figure out what the right number
is, etc), like so:

Control: close -1
Control: tags -1 wontfix

etc.

Thanks!

Stephen

* Magnus Hagander (magnus@hagander.net) wrote:
> On Wed, Oct 7, 2015 at 4:56 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > reply-all works just fine, since you like to know *exactly* how it works
> > at a technical level, I just checked and the bug email address is
> > automatically included in the Reply-To: header rather than being CC'd
> > or From.  The bug submitter's email is also in the Reply-To.
>
> Well, to play the devils advocate here - we explicitly *don't* set reply-to
> headers on our mailinglists, and have done many rounds of bikeshedding as
> to why :P

It's not a mailing list and it's probably configurable anyway.

> What I'd want is to just hit Reply-All, and add a keyword something like
> "bug: closed" to the email, and that's it.

Control: close -1

> > One thing that's important to understand is that this system (in
> > particular, the email interface) is *not* for our users (more
> > specifically, it's not for the individuals who submit bugs via the bug
> > form).
>
> It's not for our end users, at least those parts, I agree.
>
> But it's for all our developers, not just committers.

Agreed, just saying we need to realize that there is a difference
between users and individuals who are active participants in the
community (and therefore have some familiarity with our mailing lists,
etc...).

Thanks!

Stephen

Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > If you want such an API, I won't stop you from using it, but I will not
> > use it myself.  Please put in message-body commands as well.
> 
> So, unsurprisingly, debbugs does support all commands that can be sent
> to control@ also through the NNN@bugs.postgresql.org system; the command
> simply needs to be prefixed with 'Control: ' and then '-1' can be used
> as the bug number (so you don't have to figure out what the right number
> is, etc), like so:
> 
> Control: close -1
> Control: tags -1 wontfix

Supposedly we will want our traffic to still flow via
pgsql-bugs@postgresql.org, so the trick of grabbing the bug number from
the To address will not be available, will it?

Hmm, I guess we could have the bug form addTo: NNN@bugs.postgresql.orgCC: pgsql-bugs@postgresql.org
as headers, which should work for most people (since we reply-all), Josh
Berkus being the exception.

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

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > > If you want such an API, I won't stop you from using it, but I will not
> > > use it myself.  Please put in message-body commands as well.
> >
> > So, unsurprisingly, debbugs does support all commands that can be sent
> > to control@ also through the NNN@bugs.postgresql.org system; the command
> > simply needs to be prefixed with 'Control: ' and then '-1' can be used
> > as the bug number (so you don't have to figure out what the right number
> > is, etc), like so:
> >
> > Control: close -1
> > Control: tags -1 wontfix
>
> Supposedly we will want our traffic to still flow via
> pgsql-bugs@postgresql.org, so the trick of grabbing the bug number from
> the To address will not be available, will it?

There are a few different ways which we could integrate with pgsql-bugs,
depending on exactly what we want.

The Debian debbugs system currently emails to the following lists:

debian-bugs-closed - All emails which close bugs
debian-bugs-dist - All submitted bug reports and further info
debian-bugs-forwarded - Bug report forwarded upstream emails
debian-bugs-rc - All mail regarding release critical bugs

I'm sure we could create more.

The emails which go through debbugs will have the bug # pre-pended to
the Subject: line.

> Hmm, I guess we could have the bug form add
>  To: NNN@bugs.postgresql.org
>  CC: pgsql-bugs@postgresql.org
> as headers, which should work for most people (since we reply-all), Josh
> Berkus being the exception.

My thinking was that we'd have the form email submit@bugs.postgresql.org
and then have pgsql-bugs receive the emails that go to debian-bugs-dist
(basically, all email that goes through the system).  That way, the
emails which hit pgsql-bugs can be responded to with updates, changes,
etc.  To avoid duplicate emails hitting pgsql-bugs, we might need to put
in place something that checks if pgsql-bugs was on the To: or Cc: line
and, if so, the email isn't sent to it again (honestly, for all I know,
debbugs might even support doing exactly that already..).

Perhaps it'd be better to have pgsql-bugs be the "Package owner", who
also gets emails about bug activity on their packages.  That way, we
could have a 'jdbc' package whose owner is pgsql-jdbc and pgsql-bugs
wouldn't end up with that bug traffic (which, I believe, is what we'd
want...).

I'll ask Don what suggestions he has regarding the best approach.

Thanks!

Stephen

* Stephen Frost (sfrost@snowman.net) wrote:
> Perhaps it'd be better to have pgsql-bugs be the "Package owner", who
> also gets emails about bug activity on their packages.  That way, we
> could have a 'jdbc' package whose owner is pgsql-jdbc and pgsql-bugs
> wouldn't end up with that bug traffic (which, I believe, is what we'd
> want...).

To clarify, I mean 'Maintainer', and this would be identical to how the
PostgreSQL packages in Debian are currently maintained:

Maintainers for postgresql are Debian PostgreSQL Maintainers
<pkg-postgresql-public@lists.alioth.debian.org>.

And, handily, that list is archived here:

http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/

One example of how it's used can be seen with this thread:

http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html

Thanks!

Stephen

Stephen Frost wrote:
> * Stephen Frost (sfrost@snowman.net) wrote:
> > Perhaps it'd be better to have pgsql-bugs be the "Package owner", who
> > also gets emails about bug activity on their packages.  That way, we
> > could have a 'jdbc' package whose owner is pgsql-jdbc and pgsql-bugs
> > wouldn't end up with that bug traffic (which, I believe, is what we'd
> > want...).
> 
> To clarify, I mean 'Maintainer', and this would be identical to how the
> PostgreSQL packages in Debian are currently maintained:
> 
> Maintainers for postgresql are Debian PostgreSQL Maintainers
> <pkg-postgresql-public@lists.alioth.debian.org>.
> 
> And, handily, that list is archived here:
> 
> http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/
> 
> One example of how it's used can be seen with this thread:
> 
> http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html

So in the pipermail interface you get the impression that after three
messages the thread stopped.  But if you go to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
you realize that there's further traffic in the bug that wasn't sent to
the list.  That's ungood.

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

On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
> Hmm, I guess we could have the bug form add
>  To: NNN@bugs.postgresql.org
>  CC: pgsql-bugs@postgresql.org
> as headers, which should work for most people (since we reply-all), Josh
> Berkus being the exception.

Well, this will just give you more opportunities to ignore me.

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

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Stephen Frost (sfrost@snowman.net) wrote:
> > > Perhaps it'd be better to have pgsql-bugs be the "Package owner", who
> > > also gets emails about bug activity on their packages.  That way, we
> > > could have a 'jdbc' package whose owner is pgsql-jdbc and pgsql-bugs
> > > wouldn't end up with that bug traffic (which, I believe, is what we'd
> > > want...).
> >
> > To clarify, I mean 'Maintainer', and this would be identical to how the
> > PostgreSQL packages in Debian are currently maintained:
> >
> > Maintainers for postgresql are Debian PostgreSQL Maintainers
> > <pkg-postgresql-public@lists.alioth.debian.org>.
> >
> > And, handily, that list is archived here:
> >
> > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/
> >
> > One example of how it's used can be seen with this thread:
> >
> > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html
>
> So in the pipermail interface you get the impression that after three
> messages the thread stopped.  But if you go to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> you realize that there's further traffic in the bug that wasn't sent to
> the list.  That's ungood.

Oh, huh, that's curious.  I had expected all of the emails to go to the
package maintainer address also.  I'm sure they all went to the -dist
list.  I'll ask Don about it.

Thanks!

Stephen

Josh Berkus wrote:
> On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
> > Hmm, I guess we could have the bug form add
> >  To: NNN@bugs.postgresql.org
> >  CC: pgsql-bugs@postgresql.org
> > as headers, which should work for most people (since we reply-all), Josh
> > Berkus being the exception.
> 
> Well, this will just give you more opportunities to ignore me.

Currently, it just means I have to look harder for stuff you post -- I
certainly do not ignore you.  I worry that in the future it might mean
your messages don't make it to the "bug threads", if we have such a
thing.  See my followup to Stephen,
https://www.postgresql.org/message-id/20151007175841.GE4405%40alvherre.pgsql
where some traffic was not present in the mailing list archives but it
does appear in the bug report itself.  I think we need to make it very
hard for that to happen, and lack of CCs might become a problem.

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

On 2015-10-07 14:58:41 -0300, Alvaro Herrera wrote:
> Stephen Frost wrote:
> > One example of how it's used can be seen with this thread:
> > 
> > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html
> 
> So in the pipermail interface you get the impression that after three
> messages the thread stopped.  But if you go to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> you realize that there's further traffic in the bug that wasn't sent to
> the list.  That's ungood.

That's just becaue the pipermail link is for September, no?

Greetings,

Andres Freund

* Andres Freund (andres@anarazel.de) wrote:
> On 2015-10-07 14:58:41 -0300, Alvaro Herrera wrote:
> > Stephen Frost wrote:
> > > One example of how it's used can be seen with this thread:
> > >
> > > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html
> >
> > So in the pipermail interface you get the impression that after three
> > messages the thread stopped.  But if you go to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> > you realize that there's further traffic in the bug that wasn't sent to
> > the list.  That's ungood.
>
> That's just becaue the pipermail link is for September, no?

hahaha, yes. :)

Thanks!

Stephen

On 10/07/2015 11:05 AM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
>>> Hmm, I guess we could have the bug form add
>>>  To: NNN@bugs.postgresql.org
>>>  CC: pgsql-bugs@postgresql.org
>>> as headers, which should work for most people (since we reply-all), Josh
>>> Berkus being the exception.
>>
>> Well, this will just give you more opportunities to ignore me.
> 
> Currently, it just means I have to look harder for stuff you post -- I
> certainly do not ignore you.  

I know, I'm just "Joshing" you.

> I worry that in the future it might mean
> your messages don't make it to the "bug threads", if we have such a
> thing.  See my followup to Stephen,
> https://www.postgresql.org/message-id/20151007175841.GE4405%40alvherre.pgsql
> where some traffic was not present in the mailing list archives but it
> does appear in the bug report itself.  I think we need to make it very
> hard for that to happen, and lack of CCs might become a problem.

As a serious response, "reply-all" is NOT the default for common GUI
mail clients (TB, Apple, Gmail, etc.), and I know on TB that it's not
even possible to make it the default (I miss Kmail).  So a system which
depends on the user ... including outside bug reporters ... always
hitting "reply all" is going to have some issues.

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

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> So in the pipermail interface you get the impression that after three
> messages the thread stopped.  But if you go to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> you realize that there's further traffic in the bug that wasn't sent to
> the list.  That's ungood.

As Andres noted, the messages all went to the list, it's just that they
crossed a month boundary and the rest of the thread is in October.

Per Don, generally speaking, the only emails that *don't* get sent to
the Maintainer email address are ones which are explicitly sent to the
special 'nnn-quiet@bugs' email address, which is available specifically
to allow maintainers to add info without having it be sent back out to
the maintainer address.

Thanks!

Stephen

Stephen Frost wrote:
> * Andres Freund (andres@anarazel.de) wrote:
> > On 2015-10-07 14:58:41 -0300, Alvaro Herrera wrote:
> > > Stephen Frost wrote:
> > > > One example of how it's used can be seen with this thread:
> > > > 
> > > > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html
> > > 
> > > So in the pipermail interface you get the impression that after three
> > > messages the thread stopped.  But if you go to
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> > > you realize that there's further traffic in the bug that wasn't sent to
> > > the list.  That's ungood.
> > 
> > That's just becaue the pipermail link is for September, no?
> 
> hahaha, yes. :)

Oh my, how '90s.

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

Josh Berkus wrote:
> On 10/07/2015 11:05 AM, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> >> On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
> >>> Hmm, I guess we could have the bug form add
> >>>  To: NNN@bugs.postgresql.org
> >>>  CC: pgsql-bugs@postgresql.org
> >>> as headers, which should work for most people (since we reply-all), Josh
> >>> Berkus being the exception.
> >>
> >> Well, this will just give you more opportunities to ignore me.
> > 
> > Currently, it just means I have to look harder for stuff you post -- I
> > certainly do not ignore you.  
> 
> I know, I'm just "Joshing" you.

Ah well.

> > I worry that in the future it might mean
> > your messages don't make it to the "bug threads", if we have such a
> > thing.  See my followup to Stephen,
> > https://www.postgresql.org/message-id/20151007175841.GE4405%40alvherre.pgsql
> > where some traffic was not present in the mailing list archives but it
> > does appear in the bug report itself.  I think we need to make it very
> > hard for that to happen, and lack of CCs might become a problem.
> 
> As a serious response, "reply-all" is NOT the default for common GUI
> mail clients (TB, Apple, Gmail, etc.), and I know on TB that it's not
> even possible to make it the default (I miss Kmail).  So a system which
> depends on the user ... including outside bug reporters ... always
> hitting "reply all" is going to have some issues.

Hm, that's something to keep in mind then when figuring out the detailed
specs of the system.

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

* Josh Berkus (josh@agliodbs.com) wrote:
> As a serious response, "reply-all" is NOT the default for common GUI
> mail clients (TB, Apple, Gmail, etc.), and I know on TB that it's not
> even possible to make it the default (I miss Kmail).  So a system which
> depends on the user ... including outside bug reporters ... always
> hitting "reply all" is going to have some issues.

You mean like our current system?

For starters, unless we start asking our users to submit their gmail
passwords, there's no way to ensure we get all of the emails.

I *really* don't like the idea of rewriting the From/To completely to
force all mail through a relay and I'm pretty sure that "fix" would be
far worse than the problem.

debbugs, as noted previously, does set Reply-To by default, which means
that a user replying to an email (even without reply-all) from debbugs
should have the response go to both the bug and whomever responded to
the initial email.

One thing which can be easily done with debbugs is that someone can
forward or bounce the direct email they receive from the user to the
bug#@bugs address and have the info added, if the user removed the bug
email address.

Thanks!

Stephen

I have added full text searching to my tracker.  I only index the first
50 KB of each message.  There's apparently a one MB limit on that
anyway, which a few messages exceed.  I figure anything important is
probably in the first 50KB.  I could be wrong.  I could re-index fairly
easily.  It seems to work pretty well.

I have changed the 'stale' status to 90 days.  I have triaged most of
the remaining bugs with a message count > 1.  This is in a separate
file if it some other system wants to collect the work.

I am still working out exactly how to find multiple matching commits
along different branches.  I'm running git patch-id on every commit,
but that will take a while.

Later tonight I will implement some in-message-body update syntax I'm
also going to create (internally) a web page for the bugs that allows
editing the status from that page.  I will post the details on that
once I've tested it a bit.  I'll probably make a web page allowing
updates as well.

How often are the bugs mail list archives updated?  I've got a bunch of
posts to the bugs list in my inbox that aren't in the archive download.

-- 
nw

Nathan Wagner wrote:

> I am still working out exactly how to find multiple matching commits
> along different branches.  I'm running git patch-id on every commit,
> but that will take a while.

See src/tools/git_changelog (both the output and the implementation).
Isn't that rather what you want?  patch-id will give different answers
for patches that required conflict fixing.

> How often are the bugs mail list archives updated?  I've got a bunch of
> posts to the bugs list in my inbox that aren't in the archive download.

As each message is received.  What posts do you see that are not in the
archive?

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

Stephen Frost <sfrost@snowman.net> writes:
> I *really* don't like the idea of rewriting the From/To completely to
> force all mail through a relay and I'm pretty sure that "fix" would be
> far worse than the problem.

Agreed; but adding a Reply-To: header seems quite reasonable.  (Unless
gmail ignores that, which I wouldn't put past it ...)

> One thing which can be easily done with debbugs is that someone can
> forward or bounce the direct email they receive from the user to the
> bug#@bugs address and have the info added, if the user removed the bug
> email address.

Right.  But that requires the recipient to pay close attention to the
message's cc list, which I have to confess I seldom do.  Still, it's
better than nothing.
        regards, tom lane

* Nathan Wagner (nw+pg@hydaspes.if.org) wrote:
> I have added full text searching to my tracker.  I only index the first
> 50 KB of each message.  There's apparently a one MB limit on that
> anyway, which a few messages exceed.  I figure anything important is
> probably in the first 50KB.  I could be wrong.  I could re-index fairly
> easily.  It seems to work pretty well.

Note that we have FTS for the -bugs, and all the other, mailing lists..

Thanks!

Stephen

On Wed, Oct 07, 2015 at 03:06:50PM -0400, Stephen Frost wrote:
> * Nathan Wagner (nw+pg@hydaspes.if.org) wrote:
> > I have added full text searching to my tracker.  I only index the first
> > 50 KB of each message.  There's apparently a one MB limit on that
> > anyway, which a few messages exceed.  I figure anything important is
> > probably in the first 50KB.  I could be wrong.  I could re-index fairly
> > easily.  It seems to work pretty well.
> 
> Note that we have FTS for the -bugs, and all the other, mailing lists..

True, but that finds emails.  The search I have finds bugs (well, bug reports
anyway).  Specifically, I have the following function:

create or replace function bugvector(bugid bigint)
returns tsvector language 'sql' as $$
select tsvagg(       setweight(to_tsvector(substr(body(msg), 1, 50*1024)), 'D')       ||
setweight(to_tsvector(header_value(msg,'Subject')), 'C')
 
)
from emails
where bug = $1
$$ strict;

which, as you can see, collects into one tsvector all the emails associated
with that particular bug.  So a search hit is for the whole bug.  There's
probably some search artifacts here.  I suspect a bug with a long email thread
will be ranked higher than a one with a short thread.  Perhaps that's ok
though.

-- 
nw

Nathan,

If you're going further with this, one thing that we'll need is a bug
triage interface.  This is something which is better done by web; that
is, a way for volunteers to go through bugs by status, and quickly
update their status and/or post follow-up questions, and then go to the
next one in the queue.

I have yet to see a bug tracker which does this particular task well, so
please don't emulate existing art.

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

On Tue, Oct 6, 2015 at 2:33 PM, Nathan Wagner <nw+pg@hydaspes.if.org> wrote:
> 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'd personally be willing to put machine-parseable metadata into my
commit messages provided that:

1. I'm not the only one doing it - i.e. at least 3 or 4
moderately-frequent committers are all doing it consistently and all
using the same format.  If Tom buys into it, that's a big plus.

2. Adding the necessary metadata to a commit can be reasonably
expected to take no more than 2 minutes in typical cases (preferably
less).

3. Adding the metadata doesn't cause lines > 70 characters.  I am not
a fan of the "Discussion: Message-ID-Here" format which some
committers have begun using, sometimes with just the message ID and
sometimes with the full URL, because anything which causes horizontal
scrolling makes me sad.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Oct 13, 2015 at 8:36 AM, Robert Haas wrote:
> 1. I'm not the only one doing it - i.e. at least 3 or 4
> moderately-frequent committers are all doing it consistently and all
> using the same format.  If Tom buys into it, that's a big plus.
>
> 2. Adding the necessary metadata to a commit can be reasonably
> expected to take no more than 2 minutes in typical cases (preferably
> less).
>
> 3. Adding the metadata doesn't cause lines > 70 characters.  I am not
> a fan of the "Discussion: Message-ID-Here" format which some
> committers have begun using, sometimes with just the message ID and
> sometimes with the full URL, because anything which causes horizontal
> scrolling makes me sad.

Adding the discussion related to the commit directly in the log
history is really a bit plus IMO even if this breaks the rule of
you-shall-not-write-more-than-72-characters-per-line (gmail ones are
close to this limit), this allows to gain a lot of time when looking
for a particular discussion without having to go through the archives
by looking for example for the author report or a bug number, those
fields being rather helpful in general:
Discussion: Message-ID
Reviewed by: Jane Doe
Author: John Doe
[Bug Number: #XXX]
Regards,
-- 
Michael

Michael Paquier <michael.paquier@gmail.com> writes:
> On Tue, Oct 13, 2015 at 8:36 AM, Robert Haas wrote:
>> 3. Adding the metadata doesn't cause lines > 70 characters.  I am not
>> a fan of the "Discussion: Message-ID-Here" format which some
>> committers have begun using, sometimes with just the message ID and
>> sometimes with the full URL, because anything which causes horizontal
>> scrolling makes me sad.

> Adding the discussion related to the commit directly in the log
> history is really a bit plus IMO even if this breaks the rule of
> you-shall-not-write-more-than-72-characters-per-line (gmail ones are
> close to this limit), this allows to gain a lot of time when looking
> for a particular discussion without having to go through the archives
> by looking for example for the author report or a bug number, those
> fields being rather helpful in general:

Sure, but if we're adding a bug tracker that links to email, one of the
functions of the tracker can be to provide a less-verbose linking URL.

(Although I'm not sure how well that squares with the opinion I expressed
earlier that the tracker needs to link to the commit not vice versa.
It will not always be the case that a tracker entry gets made before the
commit is; besides which commit log entries cannot be fixed after the
fact.  For the same reason, I'm not that excited about embedding email
URLs in commit log entries.)

I'm with Robert on the idea that commit log entries need to be
limited-width.  I personally format them to 75 characters, so that
git_changelog's output is less than 80 characters.
        regards, tom lane

On 10/12/2015 07:36 PM, Robert Haas wrote:
> On Tue, Oct 6, 2015 at 2:33 PM, Nathan Wagner <nw+pg@hydaspes.if.org> wrote:
>> 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'd personally be willing to put machine-parseable metadata into my
> commit messages provided that:
>
> 1. I'm not the only one doing it - i.e. at least 3 or 4
> moderately-frequent committers are all doing it consistently and all
> using the same format.  If Tom buys into it, that's a big plus.

I'll do whatever everybody else agrees on.

>
> 2. Adding the necessary metadata to a commit can be reasonably
> expected to take no more than 2 minutes in typical cases (preferably
> less).
>
> 3. Adding the metadata doesn't cause lines > 70 characters.  I am not
> a fan of the "Discussion: Message-ID-Here" format which some
> committers have begun using, sometimes with just the message ID and
> sometimes with the full URL, because anything which causes horizontal
> scrolling makes me sad.
>

Perhaps we need some sort of tinyurl gadget?

BTW, a very quick look at my pg mailbox shows that message IDs are 
overwhelmingly 68 chars or less, including the surrounding <>. 68 seems 
to be a fixed width for gmail generated IDs - almost everybody else's 
message IDs are a lot smaller than 68.

cheers

andrew

On 13/10/15 04:40, Tom Lane wrote:
> I'm with Robert on the idea that commit log entries need to be 
> limited-width. I personally format them to 75 characters, so that 
> git_changelog's output is less than 80 characters. regards, tom lane 
    Little bit off-topic, but if precisely if we're trying to make the 
commits/bug-tracking/whatever system more user-friendly also for 
non-hacker users, I'd adhere to the 50/72 "standard" for commit 
messages, which seems to be quite extended: 
http://chris.beams.io/posts/git-commit/#seven-rules

(50 chars for the commit summary, 72 chars line wrapping)
    Álvaro


-- 
Álvaro Hernández Tortosa


-----------
8Kdata

On 2015-10-13 16:21:54 +0200, Álvaro Hernández Tortosa wrote:
> 
> On 13/10/15 04:40, Tom Lane wrote:
> >I'm with Robert on the idea that commit log entries need to be
> >limited-width. I personally format them to 75 characters, so that
> >git_changelog's output is less than 80 characters. regards, tom lane
> 
>     Little bit off-topic, but if precisely if we're trying to make the
> commits/bug-tracking/whatever system more user-friendly also for non-hacker
> users, I'd adhere to the 50/72 "standard" for commit messages, which seems
> to be quite extended: http://chris.beams.io/posts/git-commit/#seven-rules
> 
> (50 chars for the commit summary, 72 chars line wrapping)

-1 - imo 50 chars too often makes the commit summary too unspecific,
requiring to read much more.

Greetings,

Andres Freund

On 10/13/2015 10:21 AM, Álvaro Hernández Tortosa wrote:
>
> On 13/10/15 04:40, Tom Lane wrote:
>> I'm with Robert on the idea that commit log entries need to be 
>> limited-width. I personally format them to 75 characters, so that 
>> git_changelog's output is less than 80 characters. regards, tom lane 
>
>     Little bit off-topic, but if precisely if we're trying to make the 
> commits/bug-tracking/whatever system more user-friendly also for 
> non-hacker users, I'd adhere to the 50/72 "standard" for commit 
> messages, which seems to be quite extended: 
> http://chris.beams.io/posts/git-commit/#seven-rules
>
> (50 chars for the commit summary, 72 chars line wrapping)
>
>


50 is a pretty short for a commit summary. I've often found it quite 
difficult to write sane summaries inside that limit.

cheers

andrew

On 13/10/15 16:24, Andres Freund wrote:
> On 2015-10-13 16:21:54 +0200, Álvaro Hernández Tortosa wrote:
>> On 13/10/15 04:40, Tom Lane wrote:
>>> I'm with Robert on the idea that commit log entries need to be
>>> limited-width. I personally format them to 75 characters, so that
>>> git_changelog's output is less than 80 characters. regards, tom lane
>>      Little bit off-topic, but if precisely if we're trying to make the
>> commits/bug-tracking/whatever system more user-friendly also for non-hacker
>> users, I'd adhere to the 50/72 "standard" for commit messages, which seems
>> to be quite extended: http://chris.beams.io/posts/git-commit/#seven-rules
>>
>> (50 chars for the commit summary, 72 chars line wrapping)
> -1 - imo 50 chars too often makes the commit summary too unspecific,
> requiring to read much more.
>    I'm not strong advocate of 50 chars anyway, but if people are 
getting used to this, and probably also tools, I'd try to stick to it. 
And I believe you should be able to describe a commit in 50 chars. But 
we shouldn't of course deviate and start yet another thread on this, so 
it's all up to you :)
    Álvaro


-- 
Álvaro Hernández Tortosa


-----------
8Kdata

Andres Freund <andres@anarazel.de> writes:
> On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
>> (50 chars for the commit summary, 72 chars line wrapping)

> -1 - imo 50 chars too often makes the commit summary too unspecific,
> requiring to read much more.

I agree --- I have a hard enough time writing a good summary in 75
characters.  50 would be awful.
        regards, tom lane

On 10/13/2015 08:15 AM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
>>> (50 chars for the commit summary, 72 chars line wrapping)
>
>> -1 - imo 50 chars too often makes the commit summary too unspecific,
>> requiring to read much more.
>
> I agree --- I have a hard enough time writing a good summary in 75
> characters.  50 would be awful.

The idea of writing a commit message that is useful in a number of 
characters that is less than half a tweet sounds unbearable. The idea of 
trying to discern what the hell a commit actually is in a number of 
characters that is less than half a tweet sounds completely ridiculous.

-1 on that particular aspect.

jD

>
>             regards, tom lane
>
>


-- 
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.

On 13/10/15 17:39, Joshua D. Drake wrote:
> On 10/13/2015 08:15 AM, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
>>>> (50 chars for the commit summary, 72 chars line wrapping)
>>
>>> -1 - imo 50 chars too often makes the commit summary too unspecific,
>>> requiring to read much more.
>>
>> I agree --- I have a hard enough time writing a good summary in 75
>> characters.  50 would be awful.
>
> The idea of writing a commit message that is useful in a number of 
> characters that is less than half a tweet sounds unbearable. The idea 
> of trying to discern what the hell a commit actually is in a number of 
> characters that is less than half a tweet sounds completely ridiculous.
>
> -1 on that particular aspect.
>
> jD
>
    I'm writing a YC application and they ask you to summarize your 
whole project idea in less than 50 chars. So I guess that a commit 
message can be summarized under 50 chars too ^_^
We even do this with Java commits, and hey, you know, if you include a 
JavaStyleCamelCaseUnnecesarilyVerboseClassName in this summary you're 
screwed up!
    But it seems there's clear agreement on *not* restricting it to 50, 
so I have nothing else to add :)
    Best,
    Álvaro

-- 
Álvaro Hernández Tortosa


-----------
8Kdata

Joshua D. Drake wrote:
> On 10/13/2015 08:15 AM, Tom Lane wrote:
> >Andres Freund <andres@anarazel.de> writes:
> >>On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
> >>>(50 chars for the commit summary, 72 chars line wrapping)
> >
> >>-1 - imo 50 chars too often makes the commit summary too unspecific,
> >>requiring to read much more.
> >
> >I agree --- I have a hard enough time writing a good summary in 75
> >characters.  50 would be awful.
> 
> The idea of writing a commit message that is useful in a number of
> characters that is less than half a tweet sounds unbearable. The idea of
> trying to discern what the hell a commit actually is in a number of
> characters that is less than half a tweet sounds completely ridiculous.

There are many commits that can be summarized in small lines; new
features are often like that.  Bug fix summaries are much harder to
write and most of the time they require longer lines.  When you can
achieve 50-char lines it looks better in tooling (gitweb or git log
--oneline), but if you have to make it 75 it's not the end of the world.

http://git.postgresql.org/gitweb/?p=postgresql.git;a=shortlog

I don't care one bit if one or two lines that are part of the _body_ of
the commit messages are longer than 80 chars, particularly if they
provide useful links such as message-ids.  The message-ids or
message-id-based URLs are too handy to ignore.

A month ago I asked sysadmins@pg.org about using
http://postgr.es/m/<message-id> as a way to create shorter URLs to use
in commit messages, but the idea wasn't too hotly received so I let it
go.  I'm glad it popped up again.

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

On Tue, Oct 13, 2015 at 08:39:16AM -0700, Joshua Drake wrote:
> On 10/13/2015 08:15 AM, Tom Lane wrote:
> >Andres Freund <andres@anarazel.de> writes:
> >>On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
> >>>(50 chars for the commit summary, 72 chars line wrapping)
> >
> >>-1 - imo 50 chars too often makes the commit summary too unspecific,
> >>requiring to read much more.
> >
> >I agree --- I have a hard enough time writing a good summary in 75
> >characters.  50 would be awful.
> 
> The idea of writing a commit message that is useful in a number of
> characters that is less than half a tweet sounds unbearable. The
> idea of trying to discern what the hell a commit actually is in a
> number of characters that is less than half a tweet sounds
> completely ridiculous.
> 
> -1 on that particular aspect.

FYI, I think we already have two limits for the first line summary of
commit messages.  The limits are 64 for commit message subjects and 50
characters for gitweb summary pages --- anything longer is truncated.

My commit template shows me the limits as I am typing the commit text to
remind me of the limits:

-- email subject limit -----------------------------------------
-- gitweb summary limit --------------------------

--  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                             +

On 10/13/2015 11:41 AM, Bruce Momjian wrote:

> FYI, I think we already have two limits for the first line summary of
> commit messages.  The limits are 64 for commit message subjects and 50
> characters for gitweb summary pages --- anything longer is truncated.
>
> My commit template shows me the limits as I am typing the commit text to
> remind me of the limits:
>
> -- email subject limit -----------------------------------------
> -- gitweb summary limit --------------------------
>

So where are we at on this?

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.

* Joshua D. Drake (jd@commandprompt.com) wrote:
> On 10/13/2015 11:41 AM, Bruce Momjian wrote:
>
> >FYI, I think we already have two limits for the first line summary of
> >commit messages.  The limits are 64 for commit message subjects and 50
> >characters for gitweb summary pages --- anything longer is truncated.
> >
> >My commit template shows me the limits as I am typing the commit text to
> >remind me of the limits:
> >
> >-- email subject limit -----------------------------------------
> >-- gitweb summary limit --------------------------
>
> So where are we at on this?

On the line summary limits..?  Or the general bug tracking?

With regard to bug tracking, as I'm guessing that's what you were
getting at with the query, I have the VM built and the BTS software
mostly installed, but I don't expect to get back to working on it before
PGConf.EU, which is next week.  I need to set up the DNS and the email
routing along with general testing; perhaps I'll get that done while in
Austria or the week after.

Thanks!

Stephen

On Tue, Oct 20, 2015 at 10:39:55AM -0700, Joshua D. Drake wrote:
> So where are we at on this?

Well, I can't speak to where we are, but my system is up, running, and
seems to work well,  It even attracts a few visitors.

I have been meaning to write a triage interface, but I have been stuck
doing postgis work for an anthropology paper I am working on for the
last week.  I hope to be able to take a break from that tomorrow and
through the weekend.  I have read the various comments, and will also do
some simple scanning for phrases in emails and commit messages
indicating status changes which I will reflect on the main web page.
Once I write that code, I will email the list with what I have done.  If
people want to use it, or criticize it, they would be welcome to do so.
If not, well, the interface is useful for me in any event, so I will
probably maintain it for the forseeable future.

https://granicus.if.org/pgbugs/ for anyone who hasn't and wants to take a
look.

-- 
nw

On Thu, Oct 22, 2015 at 2:04 AM, Nathan Wagner <nw+pg@hydaspes.if.org> wrote:
> https://granicus.if.org/pgbugs/ for anyone who hasn't and wants to take a
> look.

FYI There seems to be an encoding problem somewhere.  "Đặng Minh Dũng"
is showing up as "Đặng Minh Dũng" on this page:

https://granicus.if.org/pgbugs/13691

--
Thomas Munro
http://www.enterprisedb.com