How can I check the treatment of bug fixes?

On 05/27/2011 08:36 AM, MauMau wrote:

Hello,

I posted a patch for bug #6011 to pgsql-hackers several days ago. How
can I check the status of bug fixes? I'm worried that the patch might
be forgotten, because bug #5842 was missed for two months until Bruce
noticed it.

In the immortal words of Robert Haas: "Hey, look! An elephant!"

cheers

andrew

Excerpts from Andrew Dunstan's message of vie may 27 08:53:50 -0400 2011:

In the immortal words of Robert Haas: "Hey, look! An elephant!"

This is Robert's $1000 tshirt, I think.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On 05/27/2011 05:36 AM, MauMau wrote:

Hello,

I posted a patch for bug #6011 to pgsql-hackers several days ago. How
can I check the status of bug fixes? I'm worried that the patch might be
forgotten, because bug #5842 was missed for two months until Bruce
noticed it.

The joke that my lovely colleagues are not letting you in on is,
"PostgreSQL does not believe in using a bug tracker". I personally think
that some of us are still holding on to a strange and irrational premise
that a bug tracker will somehow force the community to subjigate itself
to "the man" and therefore we just can't allow it.

Yes, it is a long standing argument.

Yes, it is ridiculous.

Yes, it is something that MySQL gets to make fun of us about (inside joke).

You have done what you need to do to check the status. Someone who knows
something about the bug should speak up at some point.

Sincerely,

Joshua D. Drake

Regards
MauMau

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
The PostgreSQL Conference - http://www.postgresqlconference.org/
@cmdpromptinc - @postgresconf - 509-416-6579

"Joshua D. Drake" <jd@commandprompt.com> writes:

You have done what you need to do to check the status. Someone who knows
something about the bug should speak up at some point.

That patch is waiting for a committer who knows something about Windows
to pick it up.

regards, tom lane

On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

You have done what you need to do to check the status. Someone who knows
something about the bug should speak up at some point.

That patch is waiting for a committer who knows something about Windows
to pick it up.

It might be useful, in this situation, for the OP to add this patch to
the CommitFest application.

https://commitfest.postgresql.org/action/commitfest_view/open

Also, I think it's about time we got ourselves some kind of bug
tracker. I have no idea how to make that work without breaking
workflow that works now, but a quick survey of my pgsql-bugs email
suggests that this is far from the only thing slipping through the
cracks.

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

Robert Haas <robertmhaas@gmail.com> writes:

On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

That patch is waiting for a committer who knows something about Windows
to pick it up.

It might be useful, in this situation, for the OP to add this patch to
the CommitFest application.

https://commitfest.postgresql.org/action/commitfest_view/open

Also, I think it's about time we got ourselves some kind of bug
tracker.

[ shrug... ] I think the main problem is a lack of committer cycles.
If so, the extra bureaucracy involved in managing a bug tracker will
make things worse, not better.

However, if someone *else* wants to do the work of entering bugs into a
tracker and updating their status, far be it from me to stand in their
way.

regards, tom lane

On Fri, May 27, 2011 at 2:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

That patch is waiting for a committer who knows something about Windows
to pick it up.

It might be useful, in this situation, for the OP to add this patch to
the CommitFest application.

https://commitfest.postgresql.org/action/commitfest_view/open

Also, I think it's about time we got ourselves some kind of bug
tracker.

[ shrug... ]  I think the main problem is a lack of committer cycles.
If so, the extra bureaucracy involved in managing a bug tracker will
make things worse, not better.

However, if someone *else* wants to do the work of entering bugs into a
tracker and updating their status, far be it from me to stand in their
way.

Definitely something to think about. But I think lack of committer
bandwidth is only part of the problem. If someone had a free day
tomorrow and wanted to flip through all the bugs that haven't had a
response and address the ones they knew something about, how would
they get a list?

And who is to say only committers can fix bugs? Actually commit the
fixes themselves, yes. Write the patches? No.

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

On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:

Also, I think it's about time we got ourselves some kind of bug
tracker. I have no idea how to make that work without breaking
workflow that works now, but a quick survey of my pgsql-bugs email
suggests that this is far from the only thing slipping through the
cracks.

The problem is finding a usable bug tracking software.

On Friday, May 27, 2011 20:39:26 Robert Haas wrote:

On Fri, May 27, 2011 at 2:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

That patch is waiting for a committer who knows something about Windows
to pick it up.

It might be useful, in this situation, for the OP to add this patch to
the CommitFest application.

https://commitfest.postgresql.org/action/commitfest_view/open

Also, I think it's about time we got ourselves some kind of bug
tracker.

[ shrug... ] I think the main problem is a lack of committer cycles.
If so, the extra bureaucracy involved in managing a bug tracker will
make things worse, not better.

However, if someone *else* wants to do the work of entering bugs into a
tracker and updating their status, far be it from me to stand in their
way.

And who is to say only committers can fix bugs? Actually commit the
fixes themselves, yes. Write the patches? No.

If I see a bug in a region I know something about and its on a platform I care
about (i.e. likely only linux) I try to do this. But its hard, in most
situations one of you already did it. Tom and you are just to goddamn fast in
many, many cases. Which is totally great, don't get me wrong, but makes it
hard to beat you as a mere mortal ;)

Do you like separate patches for the back branches or is that basically
useless work?

Related to doing stuff like that is that I really find it hard to write a patch
that happens to be liked by Tom or you so it does not have to be mostly
rewritten. For that to change for one I would like to have the Coding Style to
be expanded because I think there are loads of rules that exist only in bits
and bits on the mailing lists. For another I would like to get a patch back
instead of rewritten because without knowing the individual reasons for the
changes its sometimes rather hard to know what the reason for a specific change
was. I do realize thats quite a bit of work for you which is why I hesitated
writing that...

Andres

On Fri, May 27, 2011 at 9:24 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:

Also, I think it's about time we got ourselves some kind of bug
tracker.  I have no idea how to make that work without breaking
workflow that works now, but a quick survey of my pgsql-bugs email
suggests that this is far from the only thing slipping through the
cracks.

The problem is finding a usable bug tracking software.

On the "upside," we have gotten to the point where people that count
are finding the CommitFest application, which Is Not Simply Email, to
be an acceptable and useful thing to use.

But I don't find that I notably *like* any of the bug trackers that I
have encountered thus far. There are a few "PG-basable" options (e.g.
- RT, Bugzilla), but it's not *quite* good enough to pick something
just because it's running on our own DB.

I suspect that, from a technical perspective, the emergence of
distributed bug trackers (Fossil, SD, Bugs Everywhere), which
parallels distributed SCM (e.g. - Git) may be part of the "way to go,"
but that's still pointing at technical mechanism, as opposed to
workflow.

There is a page on the wiki documenting requirements that have been discussed:
http://wiki.postgresql.org/wiki/TrackerDiscussion

It hasn't been touched since 2008, but I expect that wiki page would
make a better starting point to restart discussion than anything else.
And it is quite likely worthwhile to consider what linkages to the
CommitFest schema/code/interfaces are relevant.

I'll also poke at SD (https://github.com/bestpractical/sd) as having
some ideas worth looking at, as it combines:
- Being inherently distributed, where bugs are assigned UUIDs as
identifiers, and where data is pulled via Git repos
- Essentially text-based, by default, so that it doesn't
assume/mandate communicating with a web server
- Somewhat agnostic of data sources; it can push/pull data to/from RT,
Hiveminder, Trac, GitHub, Google Code, and Redmine. And there's a
useful principle here: if the PostgreSQL project's issue tracker can
sync data against something like SD, then developers have extra
options. I rather wish that Slony was using one of those 6 trackers,
rather than Bugzilla, as I could use SD+adaptor, and be able to work
on issues offline.

At any rate, a useful step would be to dust off the contents of that
wiki page, and see if there are more details that are widely
agreeable. The (sometimes modest) successes of the CommitFest
application should provide some useful guidance.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

From: "Peter Eisentraut" <peter_e@gmx.net>

On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:

Also, I think it's about time we got ourselves some kind of bug
tracker. I have no idea how to make that work without breaking
workflow that works now, but a quick survey of my pgsql-bugs email
suggests that this is far from the only thing slipping through the
cracks.

The problem is finding a usable bug tracking software.

I think JIRA is very good. Almost all projects in Apache Software Foundation
(ASF) including Tomcat, Hadoop, Apache HTTP server, use JIRA. With JIRA, we
can know various counts such as the number of bugs per major/minor release,
not-fixed bugs, new features in each major release, etc.

Regards
MauMau

On 05/28/2011 05:47 AM, MauMau wrote:

From: "Peter Eisentraut" <peter_e@gmx.net>

On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:

Also, I think it's about time we got ourselves some kind of bug
tracker. I have no idea how to make that work without breaking
workflow that works now, but a quick survey of my pgsql-bugs email
suggests that this is far from the only thing slipping through the
cracks.

The problem is finding a usable bug tracking software.

I think JIRA is very good. Almost all projects in Apache Software
Foundation (ASF) including Tomcat, Hadoop, Apache HTTP server, use JIRA.
With JIRA, we can know various counts such as the number of bugs per
major/minor release, not-fixed bugs, new features in each major release,

well that is rather basic functionality of a tracker software and i
would expect those to be a given, but I don't think that is where the
problems are with implementing a tracker for postgresql.org...

Stefan

On 05/27/2011 07:55 PM, Robert Haas wrote:

On Fri, May 27, 2011 at 12:21 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

"Joshua D. Drake"<jd@commandprompt.com> writes:

You have done what you need to do to check the status. Someone who knows
something about the bug should speak up at some point.

That patch is waiting for a committer who knows something about Windows
to pick it up.

It might be useful, in this situation, for the OP to add this patch to
the CommitFest application.

https://commitfest.postgresql.org/action/commitfest_view/open

Also, I think it's about time we got ourselves some kind of bug
tracker. I have no idea how to make that work without breaking
workflow that works now, but a quick survey of my pgsql-bugs email
suggests that this is far from the only thing slipping through the
cracks.

well as for just keeping track of -bugs I guess a very simple schema
would go pretty far:

* have some tool monitor the list and if it sees a new bug# make it a
ticket/bugreport
* if that bug number is mentioned in a commit close it
* provide a dashboard of:
a) bugs that never got a response
b) bugs that got a response but never have been mentioned in a commit
c) bugs that got mentioned in a commit but no stable release was done yet
* provide a trivial interface (either mail or simple web interface -
maybe in CF style) to make issues as "not a bug" or "not postgresql-core
product" (which seems to be the top two non-big related inquiries we get
on -bugs)

this is more or less exactly what I hacked up back in early 2008 based
on bugzilla (without actually exposing the BZ User-Interface at all -
just using it as a tracker core and talking to it using the API it
provides).

Independent of whether we want to do a full tracker or not anywhere in
the future we could at least start by prototyping with better automatic
monitoring of -bugs.

Stefan

On Sat, May 28, 2011 at 10:02 AM, Stefan Kaltenbrunner
<stefan@kaltenbrunner.cc> wrote:

well as for just keeping track of -bugs I guess a very simple schema would
go pretty far:

* have some tool monitor the list and if it sees a new bug# make it a
ticket/bugreport

The bug numbers come from a database backed web form anyway - seems it
would be a lot easier to just have that script write a record to a
table.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 05/28/2011 12:19 PM, Dave Page wrote:

On Sat, May 28, 2011 at 10:02 AM, Stefan Kaltenbrunner
<stefan@kaltenbrunner.cc> wrote:

well as for just keeping track of -bugs I guess a very simple schema would
go pretty far:

* have some tool monitor the list and if it sees a new bug# make it a
ticket/bugreport

The bug numbers come from a database backed web form anyway - seems it
would be a lot easier to just have that script write a record to a
table.

maybe - but for a poc it was much easier to have something that had no
dependency on any modification of the webinfrastructure(all it needed
was an email subscription to the list), you also get some stuff like rss
feeds, XML/CSV aggregation output, a commit log parser (and a GUI for
playing even if you don't use it for anything officially) for free if
you use some existing framework ;)

For a real implemenation based on an existing tool you would probably
modify the bug reporting form to post the bug report to the tracker and
have that one send the report on behalf and with the sender address of
the original reporter, that way the -pgsql-bugs list could exactly stay
as it is now and if you wished to be able to use it as a not-only
bugreport-form triggered tracker you could do that as well.

Stefan

On Fri, May 27, 2011 at 5:54 PM, Andres Freund <andres@anarazel.de> wrote:

If I see a bug in a region I know something about and its on a platform I care
about (i.e. likely only linux) I try to do this. But its hard, in most
situations one of you already did it. Tom and you are just to goddamn fast in
many, many cases. Which is totally great, don't get me wrong, but makes it
hard to beat you as a mere mortal ;)

It's funny to be lumped in with Tom, who leaves me in the dust!

But the problem is really with the bugs that never get a response, not
the ones that do. There are no shortage of things that neither Tom
nor I nor anyone else is working on.

Do you like separate patches for the back branches or is that basically
useless work?

If it doesn't apply cleanly, yes. It's also quite helpful to identify
how far the back-patch can reasonably go, and why.

Related to doing stuff like that is that I really find it hard to write a patch
that happens to be liked by Tom or you so it does not have to be mostly
rewritten. For that to change for one I would like to have the Coding Style to
be expanded because I think there are loads of rules that exist only in bits
and bits on the mailing lists. For another I would like to get a patch back
instead of rewritten because without knowing the individual reasons for the
changes its sometimes rather hard to know what the reason for a specific change
was. I do realize thats quite a bit of work for you which is why I hesitated
writing that...

Well, frankly, I think you're doing pretty well. I find it's quite
helpful to have a patch to start with, even if I don't agree with the
approach, because it gives me an idea of what portions of the code
need to be changed and often makes it easier to understand what is
broken. But in your particular case, your recent patches have gone in
with minimal changes. I tend to avoid spelling out all the details
on-list because I don't want to be seen as nit-picking. If something
is a logic error or one or more places that needed to be changed were
altogether ignored, then I usually mention that, because those are,
well, important. But if I reindented the code to make pg_indent
mangle it less or corrected a typo in a comment or simplified
something like:

if (something)
{
do stuff;
}
else
break;
more things;

to:

if (!something)
break;
do stuff;
more things;

...then I don't tend to mention that, first because it's sort of
self-evident that the second one is clearer, second because I don't
want to demoralize people who have done basically good work by
pointing out trivial flaws, and third because it's a bit
time-consuming. But that really is third. If you want to know why I
did something, feel free to ask.

I have been really pleased to see that there is a growing group of
people who I can rely on to submit good stuff most of the time, stuff
that I can apply without spending a lot of time on it. If I were less
busy, I might spend more time hacking on patches that were marginal,
as I know Tom still does sometimes. But I just don't have the cycles
for it. It's far faster for me to read the patch and list the issues
than it is to fix them, unless the issues are trivial cosmetic stuff.
If there were fewer patches, I might spend more time hacking on
marginal patches, but as it is I mostly do that when I think that the
patch won't go in any other way. Actually, I think it's kind of good
that the volume is such as to preclude my doing that very often. It's
not so good for the patches that get bounced for lack of attention,
but I think overall the average quality of patches is improving
(perhaps partly for that reason?), and I expect that some of the
better and more prolific submitters will eventually get commit bits of
their own. I can only hope that some of those people will be
interested in helping with the CF work. It is easy to find people who
are willing to commit their own patches. Finding people who are
willing to commit other people's patches is the tough part.

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

On 05/27/2011 08:36 AM, MauMau wrote:

I posted a patch for bug #6011 to pgsql-hackers several days ago. How
can I check the status of bug fixes? I'm worried that the patch might
be forgotten, because bug #5842 was missed for two months until Bruce
noticed it.

Discussion here seems to have wandered far away from useful suggestions
for you, let's see if that's possible to return to that. Best way to
confirm when a bug is resolved is to subscribe to the pgsql-committers
mailing list. If a commit for this fix appears, odds are good the
original bug number will be referenced. Even if it isn't, you may
recognize it via its description. Until you see that, the bug is almost
certainly still open.

Bugs that are considered to impact the current version under development
are sometimes listed at http://wiki.postgresql.org/wiki/Open_Items
Adding a bug to there that's not really specific to the new version may
not be considered good form by some. It is the closest thing to an open
bug tracker around though, and adding items to there means they won't be
forgotten about; it's checked regularly by developers considering when
it's a good time to release another alpha or beta.

In my mind, clarifying what circumstances it's appropriate for people to
put a bug onto the Open Items list would be a useful way to spend a
little time. Certainly more productive than trying firing more bullets
at the unkillable zombie that is bug tracking software.

--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

well that is rather basic functionality of a tracker software and i
would expect those to be a given, but I don't think that is where the
problems are with implementing a tracker for postgresql.org...

Right, the problem has been the lukewarm response from the hackers
who would be using it every day, and without whose buy-in using a
bug tracker would be possible, but much more difficult.

Bug tracking software is definitely religious war territory; most
people have a bug tracker they use and tolerate, and pretty much
everyone has a bug tracker that they absolutely despise (hi JIRA!).
Therefore, I suggest we adopt the first one that someone takes the
time to build and implement, along with a plan for keeping it up
to date.

My own bare bones wish list for such a tracker is:

* Runs on Postgres
* Has an email interface

Make no mistake, whichever we choose, the care of feeding of such a
beast will require some precious resources in time from at least two
people, probably more. If there is anyone in the community that
wants to help the project but hasn't found a way, this is your chance
to step up! :)

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201105282322
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAk3hvCgACgkQvJuQZxSWSsi8gwCfQq/2WRhtnN8HJKoup5KxTrI6
S6QAn1rhm5QIr5cLplhz6U67ZSv6njK8
=oU4a
-----END PGP SIGNATURE-----

On Sat, May 28, 2011 at 11:23 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:

My own bare bones wish list for such a tracker is:

* Runs on Postgres
* Has an email interface

Make no mistake, whichever we choose, the care of feeding of such a
beast will require some precious resources in time from at least two
people, probably more. If there is anyone in the community that
wants to help the project but hasn't found a way, this is your chance
to step up! :)

Yeah, agreed. My basic requirements are:

1. Given a bug number, find the pgsql-bugs emails that mention it in
the subject line. Note that the archives would actually MOSTLY do
this ,but for the stupid month-boundary problem which we seem unable
to fix despite having some of the finest engineers in the world.

2. Associate some kind of status like "OPEN", "FIXED", "NOTABUG",
"WONTFIX", etc. with each such bug via web interface.

I'm not asking for a lot. In fact, less may be more. We don't want
to have to do a lot of work to keep something up to date. But for the
love of pity, there should be some way to get a list of which bugs we
haven't fixed yet.

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