Thread

How can I check the treatment of bug fixes?

MauMau <maumau307@gmail.com> — 2011-05-27T12:36:39Z

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.

Regards
MauMau

Re: How can I check the treatment of bug fixes?

Andrew Dunstan <andrew@dunslane.net> — 2011-05-27T12:53:50Z


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

Re: How can I check the treatment of bug fixes?

Alvaro Herrera <alvherre@commandprompt.com> — 2011-05-27T15:27:11Z

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

Re: How can I check the treatment of bug fixes?

Joshua D. Drake <jd@commandprompt.com> — 2011-05-27T15:37:23Z

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

Re: How can I check the treatment of bug fixes?

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-27T16:21:46Z

"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

Re: How can I check the treatment of bug fixes?

Robert Haas <robertmhaas@gmail.com> — 2011-05-27T17:55:42Z

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

Re: How can I check the treatment of bug fixes?

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-27T18:19:25Z

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

Re: How can I check the treatment of bug fixes?

Robert Haas <robertmhaas@gmail.com> — 2011-05-27T18:39:26Z

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

Re: How can I check the treatment of bug fixes?

Peter Eisentraut <peter_e@gmx.net> — 2011-05-27T21:24:14Z

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.

Re: How can I check the treatment of bug fixes?

Andres Freund <andres@anarazel.de> — 2011-05-27T21:54:35Z

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

Re: How can I check the treatment of bug fixes?

Christopher Browne <cbbrowne@gmail.com> — 2011-05-27T22:10:37Z

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?"

Re: How can I check the treatment of bug fixes?

MauMau <maumau307@gmail.com> — 2011-05-28T03:47:30Z

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

Re: How can I check the treatment of bug fixes?

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> — 2011-05-28T09:45:35Z

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

Re: How can I check the treatment of bug fixes?

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> — 2011-05-28T10:02:09Z

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

Re: How can I check the treatment of bug fixes?

Dave Page <dpage@pgadmin.org> — 2011-05-28T10:19:48Z

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

Re: How can I check the treatment of bug fixes?

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> — 2011-05-28T14:12:24Z

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

Re: How can I check the treatment of bug fixes?

Robert Haas <robertmhaas@gmail.com> — 2011-05-29T01:31:06Z

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

Re: How can I check the treatment of bug fixes?

Greg Smith <greg@2ndquadrant.com> — 2011-05-29T02:01:11Z

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

Getting a bug tracker for the Postgres project

Greg Sabino Mullane <greg@turnstep.com> — 2011-05-29T03:23:56Z

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

Re: Getting a bug tracker for the Postgres project

Robert Haas <robertmhaas@gmail.com> — 2011-05-29T03:51:57Z

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

Re: Getting a bug tracker for the Postgres project

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-29T04:04:14Z

Robert Haas <robertmhaas@gmail.com> writes:
> 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.

Many, many, many bug issues are not associated with a bug report
submitted through the web interface.  People mail stuff to pgsql-bugs
manually, or issues turn up in threads on other lists.  If a tracker
can only find things submitted through the web interface, that is not
going to lead to everyone filing bugs that way; it's going to lead to
the tracker being ignored as useless.

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

Anything that even pretends to be a bug tracker will do that.  The
real question is, who is going to keep it up to date?  GSM has the
right point of view here: we need at least a couple of people who
are willing to invest substantial amounts of time, or it's not going
to go anywhere.  Seeing that we can barely manage to keep the mailing
list moderator positions staffed, I'm not hopeful.

			regards, tom lane

Re: Getting a bug tracker for the Postgres project

Robert Haas <robertmhaas@gmail.com> — 2011-05-29T04:10:03Z

On Sun, May 29, 2011 at 12:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
>
> Many, many, many bug issues are not associated with a bug report
> submitted through the web interface.  People mail stuff to pgsql-bugs
> manually, or issues turn up in threads on other lists.  If a tracker
> can only find things submitted through the web interface, that is not
> going to lead to everyone filing bugs that way; it's going to lead to
> the tracker being ignored as useless.
>
>> 2. Associate some kind of status like "OPEN", "FIXED", "NOTABUG",
>> "WONTFIX", etc. with each such bug via web interface.
>
> Anything that even pretends to be a bug tracker will do that.  The
> real question is, who is going to keep it up to date?  GSM has the
> right point of view here: we need at least a couple of people who
> are willing to invest substantial amounts of time, or it's not going
> to go anywhere.  Seeing that we can barely manage to keep the mailing
> list moderator positions staffed, I'm not hopeful.

The issues that you raise are real ones, but doing nothing isn't
better.  Right now we have no organized tracking of ANY bugs, and if
someone were hypothetically willing to help with that they would have
nowhere to start.  This is a big enough problem that we should at
least TRY to get our arms around it.

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

Re: Getting a bug tracker for the Postgres project

Brendan Jurd <direvus@gmail.com> — 2011-05-29T04:35:17Z

On 29 May 2011 14:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Anything that even pretends to be a bug tracker will do that.  The
> real question is, who is going to keep it up to date?  GSM has the
> right point of view here: we need at least a couple of people who
> are willing to invest substantial amounts of time, or it's not going
> to go anywhere.  Seeing that we can barely manage to keep the mailing
> list moderator positions staffed, I'm not hopeful.
>

Well the good news is that first-pass triage of bug reports can be
done by pretty much anybody who is a moderately experienced postgres
user; they don't even need to be a hacker.  They just need to know
when to send back a RTFM link, when to say "you didn't tell us your PG
version" / "post your query" / "post your explain analyse" / "post
your show all", and when to kick the bug report up to a sage hacker.

It's not glamorous work, but it is a very accessible way to
contribute, without the need to block out hours at a time.  A bug
wrangler could very readily log in, sort out reports for 20 minutes
and then go do something else with the rest of their day.

Cheers,
BJ

Re: Getting a bug tracker for the Postgres project

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-29T05:23:26Z

Brendan Jurd <direvus@gmail.com> writes:
> On 29 May 2011 14:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Anything that even pretends to be a bug tracker will do that.  The
>> real question is, who is going to keep it up to date?  GSM has the
>> right point of view here: we need at least a couple of people who
>> are willing to invest substantial amounts of time, or it's not going
>> to go anywhere.  Seeing that we can barely manage to keep the mailing
>> list moderator positions staffed, I'm not hopeful.

> It's not glamorous work, but it is a very accessible way to
> contribute, without the need to block out hours at a time.  A bug
> wrangler could very readily log in, sort out reports for 20 minutes
> and then go do something else with the rest of their day.

Yup, you're right.  But the same comments can be made about mailing list
moderation, and I've lost count of the number of fails we've seen in
that domain.  Anyway, as I said earlier, I'm not standing in the way of
anybody who wants to volunteer.

			regards, tom lane

Re: Getting a bug tracker for the Postgres project

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> — 2011-05-29T08:49:16Z

On 05/29/2011 06:04 AM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.
> 
> Many, many, many bug issues are not associated with a bug report
> submitted through the web interface.  People mail stuff to pgsql-bugs
> manually, or issues turn up in threads on other lists.  If a tracker
> can only find things submitted through the web interface, that is not
> going to lead to everyone filing bugs that way; it's going to lead to
> the tracker being ignored as useless.

yeah that's why the original proposal had the plan to provide an email
interface that you could CC or forward a mail to that would turn into a
bug report, that would still require someone to actually do that, but it
is probably not different from moving a discussion on -general that
turns out to be a bug to -hackers (or -bugs).

> 
>> 2. Associate some kind of status like "OPEN", "FIXED", "NOTABUG",
>> "WONTFIX", etc. with each such bug via web interface.
> 
> Anything that even pretends to be a bug tracker will do that.  The
> real question is, who is going to keep it up to date?  GSM has the
> right point of view here: we need at least a couple of people who
> are willing to invest substantial amounts of time, or it's not going
> to go anywhere.  Seeing that we can barely manage to keep the mailing
> list moderator positions staffed, I'm not hopeful.

I think that a tracker would require a different kind of volunteer that
is much easier to find than ML-moderation, but I guess unless we
actually try we will never know.


Stefan

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-29T09:06:19Z

On sön, 2011-05-29 at 00:04 -0400, Tom Lane wrote:
> Many, many, many bug issues are not associated with a bug report
> submitted through the web interface.  People mail stuff to pgsql-bugs
> manually, or issues turn up in threads on other lists.  If a tracker
> can only find things submitted through the web interface, that is not
> going to lead to everyone filing bugs that way; it's going to lead to
> the tracker being ignored as useless.

I think this doesn't necessarily have to be the case.  I think there are
lots of hackers and users who will sign up for any reasonable bug
tracker as soon as it's introduced.  If you want a better treatment for
your bug, send it to the tracker, if you want the old-style treatment,
send it somewhere else.

That doesn't mean that better integration cannot be worked on later, but
this illusion that a bug tracker must have magical total awareness of
the entire flow of information in the project from day one is an
illusion and has blocked this business for too long IMO.

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-29T09:17:11Z

On sön, 2011-05-29 at 03:23 +0000, Greg Sabino Mullane wrote:
> My own bare bones wish list for such a tracker is:
> 
> * Runs on Postgres
> * Has an email interface

I will add

* Free/open source software

to that.

Here is a list to choose from:
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems

FLOSS with PostgreSQL backend:

OTRS
Request Tracker
LibreSource
MantisBT
Redmine
Flyspray
Roundup
Bugzilla
Trac

The next step would be to investigate the email interface capabilities
of these, and then also research how difficult they are to install and
maintain, and by that time we should be down to about three that we can
try out.

Re: Getting a bug tracker for the Postgres project

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-29T15:05:19Z

Peter Eisentraut <peter_e@gmx.net> writes:
> That doesn't mean that better integration cannot be worked on later, but
> this illusion that a bug tracker must have magical total awareness of
> the entire flow of information in the project from day one is an
> illusion and has blocked this business for too long IMO.

If it has only a partial view of the set of bugs being worked on, it's
not going to meet the goals that are being claimed for it.

I don't doubt that somebody could run around and link every discussion
about a bug into the tracker.  I'm just dubious that that actually
*will* happen with enough reliability to make the tracker more useful
than a mailing-list search.

In the end, I think that requests for a tracker mostly come from people
who are not part of this community, or at least not part of its mailing
lists (which is about the same thing IMO).  If they submitted a bug
report via the lists, they're generally going to get replies via email,
and that seems sufficient to me.  But if they submitted a report via the
web form, they might well be expecting that they can track what's going
on with it on a web page.  And that's not unreasonable.  But we could
fix that without any changes at all in our work processes.  Just have
the webform add a "cc: bugbot-bugNNNN@postgresql.org" to each submitted
email, and set up a bot to collect the traffic and display it on a
suitable web page.  (Spam filtering left as an exercise for the reader.)

			regards, tom lane

Re: Getting a bug tracker for the Postgres project

Joe Abbate <jma@freedomcircle.com> — 2011-05-29T15:47:22Z

Hi Tom,

On 05/29/2011 11:05 AM, Tom Lane wrote:
> In the end, I think that requests for a tracker mostly come from people
> who are not part of this community, or at least not part of its mailing
> lists (which is about the same thing IMO).

I think that's a bit harsh. I assume you consider GSM a part of the
community and he's asking for a tracker, even going to the trouble of
posting a "Help Wanted!" article about it.

> If they submitted a bug
> report via the lists, they're generally going to get replies via email,
> and that seems sufficient to me.  But if they submitted a report via the
> web form, they might well be expecting that they can track what's going
> on with it on a web page.  And that's not unreasonable.  But we could
> fix that without any changes at all in our work processes.  Just have
> the webform add a "cc: bugbot-bugNNNN@postgresql.org" to each submitted
> email, and set up a bot to collect the traffic and display it on a
> suitable web page.  (Spam filtering left as an exercise for the reader.)

I think there's more to a tracker than having bug submitters find all
the emails related to it. For example, one can use it to aggregate
interesting data, like how many bugs reported per person/email address,
or PostgreSQL version or OS (or may be I'm not aware and something like
this is already going on behind the submission form).

Anyway, I may be willing to do some work on a tracker--if there's
interest-- since at least part of the work could fit in with the
database interface area of the Pyrseas project.

To collect info/discuss, I could use
http://wiki.postgresql.org/wiki/TrackerDiscussion but I see there's a
request to not modify/add anything without talking to Stefan
Kaltenbrunner. Would a new page be preferable?

All the best,

Joe

Re: Getting a bug tracker for the Postgres project

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> — 2011-05-29T18:01:16Z

On 05/29/2011 05:47 PM, Joe Abbate wrote:
> Hi Tom,
> 
> On 05/29/2011 11:05 AM, Tom Lane wrote:
>> In the end, I think that requests for a tracker mostly come from people
>> who are not part of this community, or at least not part of its mailing
>> lists (which is about the same thing IMO).
> 
> I think that's a bit harsh. I assume you consider GSM a part of the
> community and he's asking for a tracker, even going to the trouble of
> posting a "Help Wanted!" article about it.
> 
>> If they submitted a bug
>> report via the lists, they're generally going to get replies via email,
>> and that seems sufficient to me.  But if they submitted a report via the
>> web form, they might well be expecting that they can track what's going
>> on with it on a web page.  And that's not unreasonable.  But we could
>> fix that without any changes at all in our work processes.  Just have
>> the webform add a "cc: bugbot-bugNNNN@postgresql.org" to each submitted
>> email, and set up a bot to collect the traffic and display it on a
>> suitable web page.  (Spam filtering left as an exercise for the reader.)

[...]

> To collect info/discuss, I could use
> http://wiki.postgresql.org/wiki/TrackerDiscussion but I see there's a
> request to not modify/add anything without talking to Stefan
> Kaltenbrunner. Would a new page be preferable?

feel free to reuse/edit the page as you like it(I have just removed the
notice) - the "don't edit" thingy was added because people started to
find the page via google (while searching for a tracker/bugreporting
tool) and considered it official status information or a way to
sell^pitch their preferred tool to me personally.



Stefan

Re: Getting a bug tracker for the Postgres project

Joe Abbate <jma@freedomcircle.com> — 2011-05-29T22:36:52Z

On 05/29/2011 02:01 PM, Stefan Kaltenbrunner wrote:
> feel free to reuse/edit the page as you like it(I have just removed the
> notice) - the "don't edit" thingy was added because people started to
> find the page via google (while searching for a tracker/bugreporting
> tool) and considered it official status information or a way to
> sell^pitch their preferred tool to me personally.

Thanks Stefan.

I've summarizes the main points made in the recent discussion and did
some minor additional research on the lists suggested by Peter and Chris
Browne.  Anyone interested in the tracker, please visit
http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
feedback/input.

All the best,

Joe

Re: Getting a bug tracker for the Postgres project

Greg Stark <gsstark@mit.edu> — 2011-05-30T02:26:21Z

On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma@freedomcircle.com> wrote:
>  Anyone interested in the tracker, please visit
> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
> feedback/input.

I think this illustrates exactly what we *don't* want to happen with a
bug tracker. We want the discussion to stay *here* not on some other
medium accessible only through the web and editable only through a web
interface....

Also your summary seems to have missed the point on the "has email
interface" requirement. The table of features you listed has just
"Creation of bugs via mail interface" as the only feature that is
accessible from email.

I'm not sure what Robert meant but I suspect he meant what I would
want which is the ability to add comments, close bugs, set other
properties, etc. By email. My biggest gripe about bugzilla was that it
sent you an email with updates to the bug but you couldn't respond to
that email.

My ideal bug tracker is the debian one which basically stays out of
your way and lets you cc any message to a specific bug at
nnnn@bugs.debian.org which archives that message in the bug and sends
it to anyone listening to the bug. And you can have control commands
to close it or edit it -- basically making all our existing "that's
not a bug bleah bleah" messages into "close nnn; that's not a bug
bleah bleah" messages.

-- 
greg

Re: Getting a bug tracker for the Postgres project

Joe Abbate <jma@freedomcircle.com> — 2011-05-30T04:32:29Z

Hi Greg,

On 05/29/2011 10:26 PM, Greg Stark wrote:
> On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma@freedomcircle.com> wrote:
>>  Anyone interested in the tracker, please visit
>> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
>> feedback/input.
> 
> I think this illustrates exactly what we *don't* want to happen with a
> bug tracker. We want the discussion to stay *here* not on some other
> medium accessible only through the web and editable only through a web
> interface....

I have no problem keeping the discussion here, but I thought perhaps not
everyone on -hackers wanted to see the discussion (there was a -tracker
list that became defunct, according to the page--don't know if people
want to resurrect it).

> Also your summary seems to have missed the point on the "has email
> interface" requirement. The table of features you listed has just
> "Creation of bugs via mail interface" as the only feature that is
> accessible from email.

My summary is in the section titled "Discussion Points" (and it was not
meant to be all-inclusive).  The second section, titled "Previous
Content" was there before and I didn't want to eliminate it entirely.
You're referring to the second section.

> I'm not sure what Robert meant but I suspect he meant what I would
> want which is the ability to add comments, close bugs, set other
> properties, etc. By email. My biggest gripe about bugzilla was that it
> sent you an email with updates to the bug but you couldn't respond to
> that email.
> 
> My ideal bug tracker is the debian one which basically stays out of
> your way and lets you cc any message to a specific bug at
> nnnn@bugs.debian.org which archives that message in the bug and sends
> it to anyone listening to the bug. And you can have control commands
> to close it or edit it -- basically making all our existing "that's
> not a bug bleah bleah" messages into "close nnn; that's not a bug
> bleah bleah" messages.

I see that a full interface is very desirable to you (and others).  That
confirms the order of my summary list of requirements (mail interface is
listed before web interface).  I'll admit that I became interest in
assisting with this effort due to the latter rather than the former, but
I don't mind carrying the ball forward, for now.

All the best,

Joe

Re: Getting a bug tracker for the Postgres project

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> — 2011-05-30T05:09:21Z

On 05/30/2011 04:26 AM, Greg Stark wrote:
> On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma@freedomcircle.com> wrote:
>>  Anyone interested in the tracker, please visit
>> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
>> feedback/input.
> 
> I think this illustrates exactly what we *don't* want to happen with a
> bug tracker. We want the discussion to stay *here* not on some other
> medium accessible only through the web and editable only through a web
> interface....
> 
> Also your summary seems to have missed the point on the "has email
> interface" requirement. The table of features you listed has just
> "Creation of bugs via mail interface" as the only feature that is
> accessible from email.
> 
> I'm not sure what Robert meant but I suspect he meant what I would
> want which is the ability to add comments, close bugs, set other
> properties, etc. By email. My biggest gripe about bugzilla was that it
> sent you an email with updates to the bug but you couldn't respond to
> that email.

well bugzilla has an inbound email interface as well that can both be
used to creande and to manipulate bugs (as in "mails that have the
bug-id in the subject will be added as a comment").
The demo installation did that by simply being subscribed to -bugs.

> 
> My ideal bug tracker is the debian one which basically stays out of
> your way and lets you cc any message to a specific bug at
> nnnn@bugs.debian.org which archives that message in the bug and sends
> it to anyone listening to the bug. And you can have control commands
> to close it or edit it -- basically making all our existing "that's
> not a bug bleah bleah" messages into "close nnn; that's not a bug
> bleah bleah" messages.

that is what every emailinterface should be able to provide ;). However
the real issue with say BZ(or most other trackers) in this role is that
in order to attribute a bug report or a comment to the original
author/person you have to trust the "From" in the email and basically
autocreate an account based on that information for the tracker to work
with.


Stefan

Re: Getting a bug tracker for the Postgres project

Greg Smith <greg@2ndquadrant.com> — 2011-05-30T05:30:37Z

On 05/29/2011 05:17 AM, Peter Eisentraut wrote:
> Here is a list to choose from:
> http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
>    

I turned this into a spreadsheet to sort and prune more easily; if 
anyone wants that let me know, it's not terribly useful beyond what I'm 
posting here.  44 total, 16 that are open-source.  I would say that 
having an e-mail interface is the next major cut to make.  While 
distasteful, it's possible for this project to adopt a solution that 
doesn't use PostgreSQL, and one interesting candidate is in that 
category.  It's not feasible to adopt one that doesn't integrate well 
with e-mail though.

List of software without listed e-mail integration:  Fossil, GNATS, 
Liberum Help Desk, MantisBT, org-mode, Flyspray, ikiwiki, Trac.

The 8 F/OSS programs left after that filter are:

OTRS
Debbugs
Request Tracker
Zentrack
LibreSource
Redmine
Roundup
Bugzilla

The next two filters you might apply are:

Support for Git:  Redmine, Bugzilla
PostgreSQL back-end:  OTRS, Request Tracker, LibreSource, Redmine, 
Roundup, Bugzilla

There are a couple of additional nice to have items I saw on the feature 
list, and they all seem to spit out just Redmine & Bugzilla.  Those are 
the two I've ended up using the most on PostgreSQL related projects, 
too, so that isn't a surprise to me.  While I'm not a strong fan of 
Redmine, it has repeatedly been the lesser of the evils available here 
for three different companies I've worked at or dealt with.

Greg Stark is right that Debbugs has a lot of interesting features 
similar to the desired workflow here.  It's not tied to just Debian 
anymore; the GNU project is also using it now.  And the database backend 
isn't that terrible to consider:  it's flat files with a BerkleyDB index 
built on top.  I think if it was perfect except for that, it would still 
be worth considering.  Debbugs is far from a general purpose solution 
though, so any customization to support differences in this project's 
workflow would likely end up being one-off hacks.  The VCS support might 
be a problem, but I've gotten the impression that git is increasingly 
popular for other Debian work.  Since the program is in Perl, I can't 
imagine it's a gigantic task to switch that out, and probably one other 
people would like to see.

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

Re: Getting a bug tracker for the Postgres project

Greg Stark <gsstark@mit.edu> — 2011-05-30T05:42:48Z

On Sun, May 29, 2011 at 10:09 PM, Stefan Kaltenbrunner
<stefan@kaltenbrunner.cc> wrote:
> well bugzilla has an inbound email interface as well that can both be
> used to creande and to manipulate bugs (as in "mails that have the
> bug-id in the subject will be added as a comment").

Ugh, putting it in the subject plays poorly with MUAs like gmail that
don't understand threading and group messages by subject.

-- 
greg

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-30T12:45:23Z

On Mon, May 30, 2011 at 04:26, Greg Stark <gsstark@mit.edu> wrote:
> On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma@freedomcircle.com> wrote:
>>  Anyone interested in the tracker, please visit
>> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
>> feedback/input.
>
> I think this illustrates exactly what we *don't* want to happen with a
> bug tracker. We want the discussion to stay *here* not on some other
> medium accessible only through the web and editable only through a web
> interface....

+<as high number as my quota currently goes>

It's fine that a bug tracker *tracks* bugs. It should not control
them. That's not how this community currently works, and a lot of
people have said that's how they want it to stay (at least for now).


> Also your summary seems to have missed the point on the "has email
> interface" requirement. The table of features you listed has just
> "Creation of bugs via mail interface" as the only feature that is
> accessible from email.
>
> I'm not sure what Robert meant but I suspect he meant what I would
> want which is the ability to add comments, close bugs, set other
> properties, etc. By email. My biggest gripe about bugzilla was that it
> sent you an email with updates to the bug but you couldn't respond to
> that email.

I agree with these too :-)

It's also missing what I believe is a very important requirement - it
needs to have an extensive, and fully supported, API. So that we can
easily make it work together with our other services.


> My ideal bug tracker is the debian one which basically stays out of
> your way and lets you cc any message to a specific bug at
> nnnn@bugs.debian.org which archives that message in the bug and sends
> it to anyone listening to the bug. And you can have control commands
> to close it or edit it -- basically making all our existing "that's
> not a bug bleah bleah" messages into "close nnn; that's not a bug
> bleah bleah" messages.

No direct experience with the debian tracker, but I agree that being
able to do all those things from mail is very important. If it *also*
provides a way to do this from the web, that's even better.

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

Re: Getting a bug tracker for the Postgres project

Kim Bisgaard <kim+pg@alleroedderne.adsl.dk> — 2011-05-30T13:56:08Z

On 2011-05-30 04:26, Greg Stark wrote:
> My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to that email.

Just checked bugzilla's list of features and they *now* lists that as supported:

> File/Modify Bugs By Email
>
> In addition to the web interface, you can send Bugzilla an email that will create a new bug, or will modify an existing bug. You can also 
> very easily attach files to bugs this way.

http://www.bugzilla.org/features/#email-in

Regards,
Kim

Re: Getting a bug tracker for the Postgres project

Alvaro Herrera <alvherre@commandprompt.com> — 2011-05-30T14:28:17Z

Excerpts from Greg Stark's message of dom may 29 22:26:21 -0400 2011:

> My ideal bug tracker is the debian one which basically stays out of
> your way and lets you cc any message to a specific bug at
> nnnn@bugs.debian.org which archives that message in the bug and sends
> it to anyone listening to the bug. And you can have control commands
> to close it or edit it -- basically making all our existing "that's
> not a bug bleah bleah" messages into "close nnn; that's not a bug
> bleah bleah" messages.

Yeah.  The other good thing about the Debian thing is that email is
first-class citizen; each "bug history" is basically an mbox.  All the
other systems I've looked at try to do the silly thing of extracting
the text from the email and inserting into a "comment" of some sort,
which is ocassionally problematic because of random annoyances in email
messages; and when you want to get down to investigating exactly what
was discussed in the email thread, the interesting bits aren't there.
In the Debian system, you can get the mbox and open it with your
favorite email reading tool instead.

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

Re: Getting a bug tracker for the Postgres project

Joe Abbate <jma@freedomcircle.com> — 2011-05-30T14:52:51Z

Hi Magnus,

On 05/30/2011 08:45 AM, Magnus Hagander wrote:
> It's fine that a bug tracker *tracks* bugs. It should not control
> them. That's not how this community currently works, and a lot of
> people have said that's how they want it to stay (at least for now).

If I may belabor the point, what do you see as an example of
"controlling" the bugs?  To put some context, there could be at least
three ways a bug could be closed when someone commits a patch that fixes
(or claims to fix) a bug:

a. The committer has to use a web interface to indicate the bug is closed
b. The committer has to send an email to a mail interface
c. The commit message gets routed to a mail interface that, seeing
something like "bug #1234" in the first line, automatically closes the bug

Based on the discussion so far, it's obvious that option b is more
desired than a (where the tracker is, in a sense, controlling *you*),
but is option c --while presumably more desirable since there's one less
thing to do or remember-- an instance of "control", since the tracker
takes an automatic action?  Or do you want the tracker *not* to require
or take any of the actions, i.e., let someone/thing other than the
committer/commit message worry about tracking the bug's status, leaving
it up to volunteers, as Tom said?

Joe

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-30T14:57:56Z

On Mon, May 30, 2011 at 16:52, Joe Abbate <jma@freedomcircle.com> wrote:
> Hi Magnus,
>
> On 05/30/2011 08:45 AM, Magnus Hagander wrote:
>> It's fine that a bug tracker *tracks* bugs. It should not control
>> them. That's not how this community currently works, and a lot of
>> people have said that's how they want it to stay (at least for now).
>
> If I may belabor the point, what do you see as an example of
> "controlling" the bugs?  To put some context, there could be at least
> three ways a bug could be closed when someone commits a patch that fixes
> (or claims to fix) a bug:
>
> a. The committer has to use a web interface to indicate the bug is closed
> b. The committer has to send an email to a mail interface
> c. The commit message gets routed to a mail interface that, seeing
> something like "bug #1234" in the first line, automatically closes the bug
>
> Based on the discussion so far, it's obvious that option b is more
> desired than a (where the tracker is, in a sense, controlling *you*),
> but is option c --while presumably more desirable since there's one less
> thing to do or remember-- an instance of "control", since the tracker
> takes an automatic action?  Or do you want the tracker *not* to require
> or take any of the actions, i.e., let someone/thing other than the
> committer/commit message worry about tracking the bug's status, leaving
> it up to volunteers, as Tom said?

I believe b is perfectly fine in this, and to me the preferred way. We
always respond to the original message with something like "yeah,
patched <over here>" or something like that anyway, so I don't
(personally) see a need for the actual commit message to be able to do
it.

The case I want to avoid is (a). And if it's possible to make (b) just
be the -hackers mailinglist and putting a keyword in the right place,
that minimizes the impact on those who spend a lot of time with it
(far more than me..), which is always good.

I personally don't think it's good to expect "external volunteers"
(external when compared to committers) to maintain *all* the bug
statuses. What I want/need those to do is to take care of everything
that the system did *not* pick up properly, or any case when the
hacker/committer forgot something, or things like that.

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

Re: Getting a bug tracker for the Postgres project

Joe Abbate <jma@freedomcircle.com> — 2011-05-30T15:27:14Z

On 05/30/2011 10:57 AM, Magnus Hagander wrote:
> The case I want to avoid is (a). And if it's possible to make (b) just
> be the -hackers mailinglist and putting a keyword in the right place,

Did you mean the -bugs mailing list?

On the subject of keywords, considering Robert's suggestion to
"Associate some kind of status like "OPEN", "FIXED", "NOTABUG",
"WONTFIX", etc. with each such bug via web interface" and considering
that most people think a mail interface is more desirable, perhaps any
email response on -bugs that takes a definite stance on a bug, i.e.,
other than keeping it OPEN, could add a status keyword at the end of the
subject line?

Joe

Re: Getting a bug tracker for the Postgres project

Christopher Browne <cbbrowne@gmail.com> — 2011-05-30T18:40:00Z

On Mon, May 30, 2011 at 2:26 AM, Greg Stark <gsstark@mit.edu> wrote:
> On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma@freedomcircle.com> wrote:
>>  Anyone interested in the tracker, please visit
>> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
>> feedback/input.
>
> I think this illustrates exactly what we *don't* want to happen with a
> bug tracker. We want the discussion to stay *here* not on some other
> medium accessible only through the web and editable only through a web
> interface....

That's more or less why I was suggesting SD as a possible model, as a
bug tracker that begins with a command line interface consciously
analogous to version management software.  (See attachment for samples
of the help...)

> Also your summary seems to have missed the point on the "has email
> interface" requirement. The table of features you listed has just
> "Creation of bugs via mail interface" as the only feature that is
> accessible from email.

I recall RT (on one of the lists) having a somewhat sophisticated
email-based interface, however, I'm not at all sure that this would be
considered a good thing, as it would be pretty "in your face" that you
are submitting specially-constructed email messages to control things.

> I'm not sure what Robert meant but I suspect he meant what I would
> want which is the ability to add comments, close bugs, set other
> properties, etc. By email. My biggest gripe about bugzilla was that it
> sent you an email with updates to the bug but you couldn't respond to
> that email.

Having used a number of versions of Bugzilla over the years, I'm
somewhat comfortable with its foibles, but that's not nearly the same
thing as actually liking it.

> My ideal bug tracker is the debian one which basically stays out of
> your way and lets you cc any message to a specific bug at
> nnnn@bugs.debian.org which archives that message in the bug and sends
> it to anyone listening to the bug. And you can have control commands
> to close it or edit it -- basically making all our existing "that's
> not a bug bleah bleah" messages into "close nnn; that's not a bug
> bleah bleah" messages.

http://www.chiark.greenend.org.uk/~ian/debbugs/

I suppose it would be interesting to inject a little more code into
this that would collect other interesting bits of data, such as the
commit hash of a patch that is believed to fix the bug, and version
numbers believed to include fixes for the bug.  Also interesting would
be a reference to commitfest work relating to the bug.

Perhaps it's enough to just send an email "to the bug" indicating
appropriate URLs, as opposed to requiring any first-class extensions
to support this sort of data.

I think we'd probably want a web interface that can point not merely
to messages, but also to the whole threads of discussion.  That way,
reporting that an email thread relates to bug 72521 requires only that
*ONE* of the messages in the thread includes "cc:
72521@bugs.postgresql.org" (or similar).
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-30T20:12:50Z

On sön, 2011-05-29 at 11:05 -0400, Tom Lane wrote:
> If it has only a partial view of the set of bugs being worked on, it's
> not going to meet the goals that are being claimed for it.
> 
> I don't doubt that somebody could run around and link every discussion
> about a bug into the tracker.  I'm just dubious that that actually
> *will* happen with enough reliability to make the tracker more useful
> than a mailing-list search.

At least initially, the bug tracker is for those who want to use it, to
help with their work.  If it eventually becomes the total-awareness
tool, that would be great, but if we make that the main goal, it will
never get started.

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-30T20:19:22Z

On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote:
> I've summarizes the main points made in the recent discussion and did
> some minor additional research on the lists suggested by Peter and
> Chris Browne.  Anyone interested in the tracker, please visit
> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
> feedback/input.

Based on that, and past discussions, and things we've tried in the past,
and gut feeling, and so on, it looks like Request Tracker would appear
to be the next best thing to consider trying out.  What do people think
about that?

Re: Getting a bug tracker for the Postgres project

Andres Freund <andres@anarazel.de> — 2011-05-30T20:21:00Z

On Monday, May 30, 2011 07:30:37 AM Greg Smith wrote:
> Trac
While I am not a fan of trac there is a plugin for that that works reasonable 
well and isn't that hard to customize if needed:
https://subtrac.sara.nl/oss/email2trac

Andres

Re: Getting a bug tracker for the Postgres project

Christopher Browne <cbbrowne@gmail.com> — 2011-05-31T00:16:56Z

On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote:
>
> On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote:
> > I've summarizes the main points made in the recent discussion and did
> > some minor additional research on the lists suggested by Peter and
> > Chris Browne.  Anyone interested in the tracker, please visit
> > http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
> > feedback/input.
>
> Based on that, and past discussions, and things we've tried in the past,
> and gut feeling, and so on, it looks like Request Tracker would appear
> to be the next best thing to consider trying out.  What do people think
> about that?

My suspicion is that RT may be rather a lot heavier weight in terms of how
it would have to affect process than people would be happy with.

What has been pretty clearly expressed is that various of the developers
prefer for the mailing lists and archives thereof to be the primary data
source and the "venue" for bug discussions.

RT, and Bugzilla, and pretty well the bulk of the issue trackers out there
are designed to themselves be the "venue" for discussions, and that's not
consistent with the preference for email discussions.

There are Debian packages for RT 3.8, and I imagine it may be worth tossing
an instance, but I'd definitely commend trying to minimize the amount of
deployment effort done, as I think there's a fair chance that a number of
devs (I'll pick on Greg Stark :-)) are liable to rebel against it.  It'd be
interesting to see the reactions to the interaction between RT, -hackers,
and -bugs for a bug or three...

I'd be more optimistic that debbugs, or an adaption thereof, might more
nearly fit into the workflow.

Re: Getting a bug tracker for the Postgres project

Robert Haas <robertmhaas@gmail.com> — 2011-05-31T01:52:38Z

On Mon, May 30, 2011 at 8:16 PM, Christopher Browne <cbbrowne@gmail.com> wrote:
> On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote:
>> On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote:
>> > I've summarizes the main points made in the recent discussion and did
>> > some minor additional research on the lists suggested by Peter and
>> > Chris Browne.  Anyone interested in the tracker, please visit
>> > http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
>> > feedback/input.
>>
>> Based on that, and past discussions, and things we've tried in the past,
>> and gut feeling, and so on, it looks like Request Tracker would appear
>> to be the next best thing to consider trying out.  What do people think
>> about that?
>
> My suspicion is that RT may be rather a lot heavier weight in terms of how
> it would have to affect process than people would be happy with.
>
> What has been pretty clearly expressed is that various of the developers
> prefer for the mailing lists and archives thereof to be the primary data
> source and the "venue" for bug discussions.
>
> RT, and Bugzilla, and pretty well the bulk of the issue trackers out there
> are designed to themselves be the "venue" for discussions, and that's not
> consistent with the preference for email discussions.
>
> There are Debian packages for RT 3.8, and I imagine it may be worth tossing
> an instance, but I'd definitely commend trying to minimize the amount of
> deployment effort done, as I think there's a fair chance that a number of
> devs (I'll pick on Greg Stark :-)) are liable to rebel against it.  It'd be
> interesting to see the reactions to the interaction between RT, -hackers,
> and -bugs for a bug or three...
>
> I'd be more optimistic that debbugs, or an adaption thereof, might more
> nearly fit into the workflow.

Yeah, that's my feeling, as well.  I have used RT and I found that the
web interface was both difficult to use and unwieldly for tickets
containing large numbers of messages.  Maybe those those things have
been improved, but frankly if RT or Bugzilla is the best we can come
up with then I'd rather not have a bug tracker at all.  See also:
Linus's opinion on CVS.

I don't personally care if I need to go to a web interface to mark
bugs closed.  Being able to do it via email is possibly useful, but I
don't really care about it personally.  Sounds like we should have it
for the benefit of those who do, but it's not my priority.  What I do
care about is that the tracker doesn't get in the way of *discussion*
of bugs.  IOW, if people just reply-to-all on bug reports as they do
now, and either include some special tag in the subject line or copy
some special address on the CC list, it should all get sucked into the
appropriate bug report.  The number of people reading and replying to
emails on pgsql-bugs is already insufficient, perhaps because of the
(incorrect) perception that Tom does or will fix everything and no one
else needs to care.  So anything that makes it harder for people to
follow along and participate is a non-starter IMV.

Based on the discussion thus far, it sounds like debbugs might be
reasonably close to what we need.

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

Re: Getting a bug tracker for the Postgres project

Brendan Jurd <direvus@gmail.com> — 2011-05-31T02:12:00Z

On 31 May 2011 11:52, Robert Haas <robertmhaas@gmail.com> wrote:
> I have used RT and I found that the
> web interface was both difficult to use and unwieldly for tickets
> containing large numbers of messages.

A big loud "ditto" from me on this point.

Cheers,
BJ

Re: Getting a bug tracker for the Postgres project

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-31T02:17:28Z

Christopher Browne <cbbrowne@gmail.com> writes:
> On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote:
>> Based on that, and past discussions, and things we've tried in the past,
>> and gut feeling, and so on, it looks like Request Tracker would appear
>> to be the next best thing to consider trying out.  What do people think
>> about that?

> I'd be more optimistic that debbugs, or an adaption thereof, might more
> nearly fit into the workflow.

Yeah, that's my impression as well.

			regards, tom lane

Re: Getting a bug tracker for the Postgres project

Kenneth Marshall <ktm@rice.edu> — 2011-05-31T02:19:21Z

On Mon, May 30, 2011 at 09:52:38PM -0400, Robert Haas wrote:
> On Mon, May 30, 2011 at 8:16 PM, Christopher Browne <cbbrowne@gmail.com> wrote:
> > On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote:
> >> On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote:
> >> > I've summarizes the main points made in the recent discussion and did
> >> > some minor additional research on the lists suggested by Peter and
> >> > Chris Browne.  Anyone interested in the tracker, please visit
> >> > http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
> >> > feedback/input.
> >>
> >> Based on that, and past discussions, and things we've tried in the past,
> >> and gut feeling, and so on, it looks like Request Tracker would appear
> >> to be the next best thing to consider trying out.  What do people think
> >> about that?
> >
> > My suspicion is that RT may be rather a lot heavier weight in terms of how
> > it would have to affect process than people would be happy with.
> >
> > What has been pretty clearly expressed is that various of the developers
> > prefer for the mailing lists and archives thereof to be the primary data
> > source and the "venue" for bug discussions.
> >
> > RT, and Bugzilla, and pretty well the bulk of the issue trackers out there
> > are designed to themselves be the "venue" for discussions, and that's not
> > consistent with the preference for email discussions.
> >
> > There are Debian packages for RT 3.8, and I imagine it may be worth tossing
> > an instance, but I'd definitely commend trying to minimize the amount of
> > deployment effort done, as I think there's a fair chance that a number of
> > devs (I'll pick on Greg Stark :-)) are liable to rebel against it.  It'd be
> > interesting to see the reactions to the interaction between RT, -hackers,
> > and -bugs for a bug or three...
> >
> > I'd be more optimistic that debbugs, or an adaption thereof, might more
> > nearly fit into the workflow.
> 
> Yeah, that's my feeling, as well.  I have used RT and I found that the
> web interface was both difficult to use and unwieldly for tickets
> containing large numbers of messages.  Maybe those those things have
> been improved, but frankly if RT or Bugzilla is the best we can come
> up with then I'd rather not have a bug tracker at all.  See also:
> Linus's opinion on CVS.
> 
> I don't personally care if I need to go to a web interface to mark
> bugs closed.  Being able to do it via email is possibly useful, but I
> don't really care about it personally.  Sounds like we should have it
> for the benefit of those who do, but it's not my priority.  What I do
> care about is that the tracker doesn't get in the way of *discussion*
> of bugs.  IOW, if people just reply-to-all on bug reports as they do
> now, and either include some special tag in the subject line or copy
> some special address on the CC list, it should all get sucked into the
> appropriate bug report.  The number of people reading and replying to
> emails on pgsql-bugs is already insufficient, perhaps because of the
> (incorrect) perception that Tom does or will fix everything and no one
> else needs to care.  So anything that makes it harder for people to
> follow along and participate is a non-starter IMV.
> 
> Based on the discussion thus far, it sounds like debbugs might be
> reasonably close to what we need.
> 
> -- 
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
> 

We use RT here and it is very customizable. In particular, it is easy
to have the basic process be completely via Email, if desired. It seems
that the general opinion is to use Email and consolidate the information
in the bug tracking system. RT can definitely step into the background
as needed.

Regards,
Ken

Re: Getting a bug tracker for the Postgres project

Andrew Dunstan <andrew@dunslane.net> — 2011-05-31T02:43:20Z

On 05/30/2011 09:52 PM, Robert Haas wrote:
> I have used RT and I found that the
> web interface was both difficult to use and unwieldly for tickets
> containing large numbers of messages.  Maybe those those things have
> been improved, but frankly if RT or Bugzilla is the best we can come
> up with then I'd rather not have a bug tracker at all.  See also:
> Linus's opinion on CVS.
>
>

This is just the sort of argument that's stopped us in the past. My 
guess that that everybody's favourite tracker is someone else's least 
favourite.

I have a slight preference for Bugzilla for no other reasons than 
familiarity and the fact that I did a good deal of the work that allowed 
it to run on Postgres some years ago. Also, I'd be happier if we could 
leverage the good work that Stefan did a few years ago.

Some years ago I was involved in doing a substantial study of trackers 
and SCMs for a company I was working for. One of the conclusions the 
study group came to was that there should be good integration between 
the tracker system and the SCM. That was in the days before distributed 
SCMs were common, and in a commercial context, so I'm not sure how well 
our reasoning would stand up for the current context, but I see it's 
been mentioned elsewhere and I think it's a significant consideration, 
at least.

cheers

andrew

Re: Getting a bug tracker for the Postgres project

Greg Stark <gsstark@mit.edu> — 2011-05-31T03:08:28Z

On Mon, May 30, 2011 at 6:52 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>  The number of people reading and replying to
> emails on pgsql-bugs is already insufficient, perhaps because of the
> (incorrect) perception that Tom does or will fix everything and no one
> else needs to care.  So anything that makes it harder for people to
> follow along and participate is a non-starter IMV.

Actually I think most of our bugs don't come in from pgsql-bugs. I
think we want to add other bugs that come up from discussions on
-hackers or -general which for whatever reason don't get immediately
fixed. The important thing about a bug tracker is that it has all the
bugs (at least all the ones you intend to fix) so they don't get
forgotten about. Keeping a single list takes the stress off
individuals trying to remember what needs to get done.

I'm actually not nearly so concerned as other people that it contain
all the detailed discussion of the bug -- we can always search for the
bug# on the list or follow links on the bug tracker.

Fwiw it is pretty nice to be able to include a "Closes: #1001" in the
commit and have that close the bug and associate the commit to the
commit as soon as it's pushed. Anything to make keeping things clean
and up to date as simple and low-overhead as possible.

-- 
greg

Re: Getting a bug tracker for the Postgres project

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-31T03:42:27Z

Kim Bisgaard <kim+pg@alleroedderne.adsl.dk> writes:
> On 2011-05-30 04:26, Greg Stark wrote:
>> My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to that email.

> Just checked bugzilla's list of features and they *now* lists that as supported:

>> File/Modify Bugs By Email
>> 
>> In addition to the web interface, you can send Bugzilla an email that will create a new bug, or will modify an existing bug. You can also 
>> very easily attach files to bugs this way.

The claim is there all right, but the feature seems spectacularly
undocumented otherwise.  I wanted to see if it worked like debbugs
(ie, you just cc: some mail to the bug tracker), but there's no
information about exactly how to use it.

			regards, tom lane

Re: Getting a bug tracker for the Postgres project

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> — 2011-05-31T05:08:38Z

On 05/31/2011 05:42 AM, Tom Lane wrote:
> Kim Bisgaard <kim+pg@alleroedderne.adsl.dk> writes:
>> On 2011-05-30 04:26, Greg Stark wrote:
>>> My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to that email.
> 
>> Just checked bugzilla's list of features and they *now* lists that as supported:
> 
>>> File/Modify Bugs By Email
>>>
>>> In addition to the web interface, you can send Bugzilla an email that will create a new bug, or will modify an existing bug. You can also 
>>> very easily attach files to bugs this way.
> 
> The claim is there all right, but the feature seems spectacularly
> undocumented otherwise.  I wanted to see if it worked like debbugs
> (ie, you just cc: some mail to the bug tracker), but there's no
> information about exactly how to use it.

Depends on what exactly you are looking for...

* that feature relies on finding a valid bugid in the subject, if it
finds one it will add the email ass a comment
* if you would prefer something like nnnnnn-bug@tracker.postgresql.org
for adding to existing bugs, that would be a trivial thing to add as a
feature(have the MTA split the localpart and pass it as a parameter in
the pipe-transport to the email_in.pl script)
* the challenge is more about creating "new" bugs, because for that you
need a bz account (or maybe a community account in our case) by default.
We could certainly modify the feature so that it will autocreate bz
accounts as soon as we see a new emailaddress sending email in but that
will be fairly hard to control spamwise.

Stefan

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-31T08:01:48Z

On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote:
> One of the conclusions the study group came to was that there should
> be good integration between the tracker system and the SCM. That was
> in the days before distributed SCMs were common, and in a commercial
> context, so I'm not sure how well our reasoning would stand up for the
> current context, but I see it's been mentioned elsewhere and I think
> it's a significant consideration, at least.

What kind of functionality would (good) SCM integration provide?

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-31T08:03:10Z

On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote:
> The number of people reading and replying to
> emails on pgsql-bugs is already insufficient, perhaps because of the
> (incorrect) perception that Tom does or will fix everything and no one
> else needs to care.  So anything that makes it harder for people to
> follow along and participate is a non-starter IMV. 

Or the number of people usefully participating in pgsql-bugs is low
because it is a waste of time to try to do anything useful there without
appropriate tracker support.

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-31T08:10:48Z

On mån, 2011-05-30 at 20:16 -0400, Christopher Browne wrote:
> My suspicion is that RT may be rather a lot heavier weight in terms of
> how it would have to affect process than people would be happy with.
> 
> 
> What has been pretty clearly expressed is that various of the
> developers prefer for the mailing lists and archives thereof to be the
> primary data source and the "venue" for bug discussions.
> 
> RT, and Bugzilla, and pretty well the bulk of the issue trackers out
> there are designed to themselves be the "venue" for discussions, and
> that's not consistent with the preference for email discussions.

> I'd be more optimistic that debbugs, or an adaption thereof, might
> more nearly fit into the workflow. 

Any bug tracker that has an adequate email interface will be isomorphic
in terms of how intrusive it is.

So I think your argument above is merely a reflection of how people have
traditionally used these systems, not how they have to be used.

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-31T08:12:43Z

On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote:
> I have used RT and I found that the
> web interface was both difficult to use and unwieldly for tickets
> containing large numbers of messages.  Maybe those those things have
> been improved, but frankly if RT or Bugzilla is the best we can come
> up with then I'd rather not have a bug tracker at all. 

Given that you have been one of the people calling for a bug tracker,
and these are the two most widely used systems available, what's wrong
with them and what else would you suggest?

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-31T08:31:10Z

On Mon, May 30, 2011 at 07:42, Greg Stark <gsstark@mit.edu> wrote:
> On Sun, May 29, 2011 at 10:09 PM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc> wrote:
>> well bugzilla has an inbound email interface as well that can both be
>> used to creande and to manipulate bugs (as in "mails that have the
>> bug-id in the subject will be added as a comment").
>
> Ugh, putting it in the subject plays poorly with MUAs like gmail that
> don't understand threading and group messages by subject.

+<a lot>. Changing the subject will break a lot of things - it's
annoying enough already with people who do that (when they shouldn't -
doing it when the thread actually changes, is obviously good)

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

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-31T08:36:47Z

On Tue, May 31, 2011 at 07:08, Stefan Kaltenbrunner
<stefan@kaltenbrunner.cc> wrote:
> On 05/31/2011 05:42 AM, Tom Lane wrote:
>> Kim Bisgaard <kim+pg@alleroedderne.adsl.dk> writes:
>>> On 2011-05-30 04:26, Greg Stark wrote:
>>>> My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to that email.
>>
>>> Just checked bugzilla's list of features and they *now* lists that as supported:
>>
>>>> File/Modify Bugs By Email
>>>>
>>>> In addition to the web interface, you can send Bugzilla an email that will create a new bug, or will modify an existing bug. You can also
>>>> very easily attach files to bugs this way.
>>
>> The claim is there all right, but the feature seems spectacularly
>> undocumented otherwise.  I wanted to see if it worked like debbugs
>> (ie, you just cc: some mail to the bug tracker), but there's no
>> information about exactly how to use it.
>
> Depends on what exactly you are looking for...
>
> * that feature relies on finding a valid bugid in the subject, if it
> finds one it will add the email ass a comment
> * if you would prefer something like nnnnnn-bug@tracker.postgresql.org
> for adding to existing bugs, that would be a trivial thing to add as a
> feature(have the MTA split the localpart and pass it as a parameter in
> the pipe-transport to the email_in.pl script)
> * the challenge is more about creating "new" bugs, because for that you
> need a bz account (or maybe a community account in our case) by default.
> We could certainly modify the feature so that it will autocreate bz
> accounts as soon as we see a new emailaddress sending email in but that
> will be fairly hard to control spamwise.

Yikes. (On the very last point there)

But.

I get the feeling we're approaching this backwards. Wouldn't the
normal way to do it be to define the workflow we *want*, and then
figure out which bugtracker works for that or requires the least
changes for that, rather than to try to figure out which bugtracker we
want and then see how much we have to change our workflow to match?
The previous way is kind of what we did with the CF app, and while I
have some things I want fixed in that one they are details - the
process seems to work fine.

So in order to start a brand new bikeshed to paint on, have we even
considered a very trivial workflow like letting the bugtracker
actually *only* track our existing lists and archives. That would
mean:

* Mailing lists are *primary*, and the mailing list archives are
*primary* (yes, this probably requires a fix to the archives, but that
really is a different issue)
* New bugs are added by simply saying "this messageid represents a
thread that has this bug in it", and all the actual contents are
pulled from the archives
* On top of this, the bug just tracks metadata - such as open/closed
more or less. It does *not* track the actual contents at all.
* Bugs registered through the bugs form would of course automatically
add such a messageid into the tracker.

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

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-31T08:42:08Z

On mån, 2011-05-30 at 22:17 -0400, Tom Lane wrote:
> Christopher Browne <cbbrowne@gmail.com> writes:
> > On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote:
> >> Based on that, and past discussions, and things we've tried in the past,
> >> and gut feeling, and so on, it looks like Request Tracker would appear
> >> to be the next best thing to consider trying out.  What do people think
> >> about that?
> 
> > I'd be more optimistic that debbugs, or an adaption thereof, might more
> > nearly fit into the workflow.
> 
> Yeah, that's my impression as well.

I'm very familiar with debbugs, so if we'd use that, I would hit the
ground running.

But a few things to consider:

      * You would probably need a lot of manpower to customize and
        maintain this thing.  And you'd be dealing with lots of
        unfamiliar technology.
      * Only very few people in Debian know the internals of this thing,
        so don't expect much timely help.
      * The actual workflow in Debian doesn't only consist of debbugs,
        but a bunch of ad hoc add-ons, additional web interfaces, and
        scripts.  You'd have to adapt or port or replace some of these
        as well.
      * It's not a system set up for easy searching and aggregating, the
        sort of thing an SQL-savvy crowd might expect.  One of the
        better ways nowadays to search for bugs in Debian is actually
        the UDD, which is a dump of the bug database imported into a
        PostgreSQL instance.  See previous point.
      * Actually, a number of teams in Debian use Request Tracker as
        well (see http://wiki.debian.org/rt.debian.org).  I don't know
        why, just saying.

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-31T08:49:42Z

On mån, 2011-05-30 at 01:30 -0400, Greg Smith wrote:
> Greg Stark is right that Debbugs has a lot of interesting features 
> similar to the desired workflow here.  It's not tied to just Debian 
> anymore; the GNU project is also using it now. 

For the benefit of others, I suppose you are referring to this:
http://debbugs.gnu.org/

This is actually pretty exciting news, as it alleviates the main concern
with debbugs, that's is in practice impossible to use outside of Debian.
(The other nice thing is that those GNU projects have also been lacking
a good bug tracker in the past.)

Should we find the people behind this project and ask them to share some
experiences?

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-31T09:47:07Z

On tis, 2011-05-31 at 10:36 +0200, Magnus Hagander wrote:
> I get the feeling we're approaching this backwards. Wouldn't the
> normal way to do it be to define the workflow we *want*, and then
> figure out which bugtracker works for that or requires the least
> changes for that, rather than to try to figure out which bugtracker we
> want and then see how much we have to change our workflow to match?

Maybe you are assuming that there is a single workflow that everyone
wants.  So far we know that most people want to work by email and want
to know that a bug is closed.  Is there more detail than that that we
can extract?

> So in order to start a brand new bikeshed to paint on, have we even
> considered a very trivial workflow like letting the bugtracker
> actually *only* track our existing lists and archives. That would
> mean:
> 
> * Mailing lists are *primary*, and the mailing list archives are
> *primary* (yes, this probably requires a fix to the archives, but that
> really is a different issue)
> * New bugs are added by simply saying "this messageid represents a
> thread that has this bug in it", and all the actual contents are
> pulled from the archives
> * On top of this, the bug just tracks metadata - such as open/closed
> more or less. It does *not* track the actual contents at all.
> * Bugs registered through the bugs form would of course automatically
> add such a messageid into the tracker.

Well, that is not a workflow either, it's approaching the issue by
proposing an implementation.  Nothing says that an existing or new
system doesn't work exactly like that.  I would be concerned about the
search capabilities of such a system, however.

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-31T10:41:30Z

On Tue, May 31, 2011 at 11:47, Peter Eisentraut <peter_e@gmx.net> wrote:
> On tis, 2011-05-31 at 10:36 +0200, Magnus Hagander wrote:
>> I get the feeling we're approaching this backwards. Wouldn't the
>> normal way to do it be to define the workflow we *want*, and then
>> figure out which bugtracker works for that or requires the least
>> changes for that, rather than to try to figure out which bugtracker we
>> want and then see how much we have to change our workflow to match?
>
> Maybe you are assuming that there is a single workflow that everyone
> wants.  So far we know that most people want to work by email and want
> to know that a bug is closed.  Is there more detail than that that we
> can extract?

Yeah, there might definitely be more than one.


>> So in order to start a brand new bikeshed to paint on, have we even
>> considered a very trivial workflow like letting the bugtracker
>> actually *only* track our existing lists and archives. That would
>> mean:
>>
>> * Mailing lists are *primary*, and the mailing list archives are
>> *primary* (yes, this probably requires a fix to the archives, but that
>> really is a different issue)
>> * New bugs are added by simply saying "this messageid represents a
>> thread that has this bug in it", and all the actual contents are
>> pulled from the archives
>> * On top of this, the bug just tracks metadata - such as open/closed
>> more or less. It does *not* track the actual contents at all.
>> * Bugs registered through the bugs form would of course automatically
>> add such a messageid into the tracker.
>
> Well, that is not a workflow either, it's approaching the issue by
> proposing an implementation.  Nothing says that an existing or new

Um, good point. I still stand by my argument though, even if I'm
arguing against myself :-)

> system doesn't work exactly like that.  I would be concerned about the
> search capabilities of such a system, however.

We already have a search system that works reasonably well for the archives...

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

Re: How can I check the treatment of bug fixes?

MauMau <maumau307@gmail.com> — 2011-05-31T11:57:19Z

From: "Robert Haas" <robertmhaas@gmail.com>
> 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

"Greg Smith" <greg@2ndQuadrant.com> wrote in message 
news:4DE1A8E7.1030601@2ndQuadrant.com...
> 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.

Thank you. I understood that it's the best and perhaps only way to search 
the pgsql-committers mail archive periodically. I would be happy if some 
bug/issue tracker could kindly notify the issuer of status changes via 
email.

I'll add my patch to either of CommitFest or Open Items list a few days 
later. (But I'm reluctant to pollute those pages with bug fixes which apply 
to previous versions. That can't be helped.)

Regards
MauMau

Re: Getting a bug tracker for the Postgres project

Andrew Dunstan <andrew@dunslane.net> — 2011-05-31T12:44:30Z

On 05/31/2011 06:41 AM, Magnus Hagander wrote:
> We already have a search system that works reasonably well for the archives...
>

I trust this weas a piece of sarcasm. I spoke to more than a few people 
at pgcon and nobody had a good word to say about the search system on 
the archives.

cheers

andrew

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-31T12:58:02Z

On Tue, May 31, 2011 at 14:44, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 05/31/2011 06:41 AM, Magnus Hagander wrote:
>>
>> We already have a search system that works reasonably well for the
>> archives...
>>
>
> I trust this weas a piece of sarcasm. I spoke to more than a few people at
> pgcon and nobody had a good word to say about the search system on the
> archives.

Well, it's tsearch. And I've heard nobody say anything else than that
it's *a lot* better than what we had before.

But sure, it can probably be improved. But what people are then
basically asying is that tsearch isn't good enough for searching.
Which is too bad, but may be so, and in that case we need to fix
*that*, rather than build Yet Another Service To Do The Same Thing
Slightly Differently.

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

Re: Getting a bug tracker for the Postgres project

Andrew Dunstan <andrew@dunslane.net> — 2011-05-31T13:07:50Z

On 05/31/2011 04:01 AM, Peter Eisentraut wrote:
> On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote:
>> One of the conclusions the study group came to was that there should
>> be good integration between the tracker system and the SCM. That was
>> in the days before distributed SCMs were common, and in a commercial
>> context, so I'm not sure how well our reasoning would stand up for the
>> current context, but I see it's been mentioned elsewhere and I think
>> it's a significant consideration, at least.
> What kind of functionality would (good) SCM integration provide?
>

Well, the most obvious one is that when a commit (or merge or push) is 
made  that fixes a bug, the bug is annotated and its status updated. I 
know I've wasted plenty of time in the past first hunting for bugs and 
then hunting for the fixes, which aren't always clear from the commit 
messages.

In a more centralized system you can also have fairly tightly integrated 
workflow (e.g. you can have the tracker open a branch when a bug is 
assigned, and you can prevent one being created without an issue being 
assigned) but that doesn't seem like such a good fit for us, nor for 
anyone using a distributed system like git. You could also argue that 
it's a bad thing for commercial organizations, but that's a debate for 
another place. The reason we wanted such a thing is that we were 
spending significant time managing the workflow issues, and doing tidy up.

cheers

andrew

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-31T13:19:23Z

On tis, 2011-05-31 at 08:44 -0400, Andrew Dunstan wrote:
> 
> On 05/31/2011 06:41 AM, Magnus Hagander wrote:
> > We already have a search system that works reasonably well for the archives...
> >
> 
> I trust this weas a piece of sarcasm. I spoke to more than a few people 
> at pgcon and nobody had a good word to say about the search system on 
> the archives.

To some degree, the lack of a good search for the archives is half the
problem.  Not that a better search would be a replacement for a bug
tracker, but it would go a long way.

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-31T13:30:15Z

On Tue, May 31, 2011 at 15:07, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 05/31/2011 04:01 AM, Peter Eisentraut wrote:
>>
>> On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote:
>>>
>>> One of the conclusions the study group came to was that there should
>>> be good integration between the tracker system and the SCM. That was
>>> in the days before distributed SCMs were common, and in a commercial
>>> context, so I'm not sure how well our reasoning would stand up for the
>>> current context, but I see it's been mentioned elsewhere and I think
>>> it's a significant consideration, at least.
>>
>> What kind of functionality would (good) SCM integration provide?
>>
>
>
> Well, the most obvious one is that when a commit (or merge or push) is made
>  that fixes a bug, the bug is annotated and its status updated. I know I've
> wasted plenty of time in the past first hunting for bugs and then hunting
> for the fixes, which aren't always clear from the commit messages.

As long as we properly track email, we don't actually need a direct
integration with the SCM for this - since we send the commit message
out to the -committers list anyway, we just need to pick it up there.


> In a more centralized system you can also have fairly tightly integrated
> workflow (e.g. you can have the tracker open a branch when a bug is
> assigned, and you can prevent one being created without an issue being
> assigned) but that doesn't seem like such a good fit for us, nor for anyone
> using a distributed system like git. You could also argue that it's a bad
> thing for commercial organizations, but that's a debate for another place.
> The reason we wanted such a thing is that we were spending significant time
> managing the workflow issues, and doing tidy up.

Yeah, that does sound like a very bad idea *for us*.


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

Re: Getting a bug tracker for the Postgres project

Kenneth Marshall <ktm@rice.edu> — 2011-05-31T13:30:21Z

On Tue, May 31, 2011 at 02:58:02PM +0200, Magnus Hagander wrote:
> On Tue, May 31, 2011 at 14:44, Andrew Dunstan <andrew@dunslane.net> wrote:
> >
> >
> > On 05/31/2011 06:41 AM, Magnus Hagander wrote:
> >>
> >> We already have a search system that works reasonably well for the
> >> archives...
> >>
> >
> > I trust this weas a piece of sarcasm. I spoke to more than a few people at
> > pgcon and nobody had a good word to say about the search system on the
> > archives.
> 
> Well, it's tsearch. And I've heard nobody say anything else than that
> it's *a lot* better than what we had before.
> 
> But sure, it can probably be improved. But what people are then
> basically asying is that tsearch isn't good enough for searching.
> Which is too bad, but may be so, and in that case we need to fix
> *that*, rather than build Yet Another Service To Do The Same Thing
> Slightly Differently.
> 
> -- 
>  Magnus Hagander
>  Me: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/
> 

I do agree that the current archive search is much, much better than
the searching before the upgrade. I would be interested in taking a
look at some open source projects with a "good" search engine. Most
projects have search engines that are true exercises in frustration
by pulling either apparently everything or next to nothing and nothing
in between. If there is a good one to look at maybe we can do some
tweaking our search engine to improve it.

Regards,
Ken

Re: Getting a bug tracker for the Postgres project

Robert Haas <robertmhaas@gmail.com> — 2011-05-31T13:33:33Z

On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote:
>> I have used RT and I found that the
>> web interface was both difficult to use and unwieldly for tickets
>> containing large numbers of messages.  Maybe those those things have
>> been improved, but frankly if RT or Bugzilla is the best we can come
>> up with then I'd rather not have a bug tracker at all.
>
> Given that you have been one of the people calling for a bug tracker,
> and these are the two most widely used systems available, what's wrong
> with them and what else would you suggest?

IIRC, both of them think that you should log into the web interface to
send emails (which, in the case of Bugzilla, don't permit replies),
rather than sending emails that show up in the web interface.  But the
web interface is, at least in RT, also seems to be pretty rudimentary.

Suppose you have a thread with 40 emails in it.  View that thread in
Gmail.  Now view it in RT.  In RT, you will notice that there's no way
to unexpand emails, and all of the data is loaded with the page, so
you sit there for half a minute waiting for everything to load.
There's also no suppression of duplicated or quoted meterial, as Gmail
does.  It's usable, I guess, but it's a long way from
state-of-the-art.

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

Re: Getting a bug tracker for the Postgres project

Robert Haas <robertmhaas@gmail.com> — 2011-05-31T13:34:51Z

On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus@hagander.net> wrote:
> I get the feeling we're approaching this backwards. Wouldn't the
> normal way to do it be to define the workflow we *want*, and then
> figure out which bugtracker works for that or requires the least
> changes for that, rather than to try to figure out which bugtracker we
> want and then see how much we have to change our workflow to match?
> The previous way is kind of what we did with the CF app, and while I
> have some things I want fixed in that one they are details - the
> process seems to work fine.
>
> So in order to start a brand new bikeshed to paint on, have we even
> considered a very trivial workflow like letting the bugtracker
> actually *only* track our existing lists and archives. That would
> mean:
>
> * Mailing lists are *primary*, and the mailing list archives are
> *primary* (yes, this probably requires a fix to the archives, but that
> really is a different issue)
> * New bugs are added by simply saying "this messageid represents a
> thread that has this bug in it", and all the actual contents are
> pulled from the archives
> * On top of this, the bug just tracks metadata - such as open/closed
> more or less. It does *not* track the actual contents at all.
> * Bugs registered through the bugs form would of course automatically
> add such a messageid into the tracker.

That's pretty much exactly what I think would be most useful.

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

Re: Getting a bug tracker for the Postgres project

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-31T13:36:00Z

Andrew Dunstan <andrew@dunslane.net> writes:
> On 05/31/2011 06:41 AM, Magnus Hagander wrote:
>> We already have a search system that works reasonably well for the archives...

> I trust this weas a piece of sarcasm. I spoke to more than a few people 
> at pgcon and nobody had a good word to say about the search system on 
> the archives.

Please note, though, that there is no bug tracker anywhere whose search
mechanism doesn't suck as much or more.  If you're unhappy with the
search stuff the solution is to improve it, not bring in another bad
mechanism.

			regards, tom lane

Re: Getting a bug tracker for the Postgres project

Kenneth Marshall <ktm@rice.edu> — 2011-05-31T13:58:30Z

On Tue, May 31, 2011 at 09:33:33AM -0400, Robert Haas wrote:
> On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote:
> >> I have used RT and I found that the
> >> web interface was both difficult to use and unwieldly for tickets
> >> containing large numbers of messages.  Maybe those those things have
> >> been improved, but frankly if RT or Bugzilla is the best we can come
> >> up with then I'd rather not have a bug tracker at all.
> >
> > Given that you have been one of the people calling for a bug tracker,
> > and these are the two most widely used systems available, what's wrong
> > with them and what else would you suggest?
> 
> IIRC, both of them think that you should log into the web interface to
> send emails (which, in the case of Bugzilla, don't permit replies),
> rather than sending emails that show up in the web interface.  But the
> web interface is, at least in RT, also seems to be pretty rudimentary.
> 
If you use the commands-by-email with RT you can do most things with
Email.

> Suppose you have a thread with 40 emails in it.  View that thread in
> Gmail.  Now view it in RT.  In RT, you will notice that there's no way
> to unexpand emails, and all of the data is loaded with the page, so
> you sit there for half a minute waiting for everything to load.
> There's also no suppression of duplicated or quoted meterial, as Gmail
> does.  It's usable, I guess, but it's a long way from
> state-of-the-art.
> 
You can adjust what RT will display in the interface and the latest
release does include some enhanced duplicate/quoted material suppression.
Note, I am not pushing for RT necessarily just trying to keep information
available.

Regards,
Ken

Re: Getting a bug tracker for the Postgres project

Andrew Dunstan <andrew@dunslane.net> — 2011-05-31T13:59:31Z


On 05/31/2011 09:33 AM, Robert Haas wrote:
> IIRC, both of them think that you should log into the web interface to
> send emails (which, in the case of Bugzilla, don't permit replies),
> rather than sending emails that show up in the web interface.

I think you probably need to look at Bugzilla again. Here's what the 
current feature page at <http://www.bugzilla.org/features/#email-in> says:

    In addition to the web interface, you can send Bugzilla an email
    that will create a new bug, or will modify an existing bug.


cheers

andrew

Re: Getting a bug tracker for the Postgres project

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-31T14:02:21Z

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> So in order to start a brand new bikeshed to paint on, have we even
>> considered a very trivial workflow like letting the bugtracker
>> actually *only* track our existing lists and archives. That would
>> mean:
>> 
>> * Mailing lists are *primary*, and the mailing list archives are
>> *primary* (yes, this probably requires a fix to the archives, but that
>> really is a different issue)
>> * New bugs are added by simply saying "this messageid represents a
>> thread that has this bug in it", and all the actual contents are
>> pulled from the archives
>> * On top of this, the bug just tracks metadata - such as open/closed
>> more or less. It does *not* track the actual contents at all.
>> * Bugs registered through the bugs form would of course automatically
>> add such a messageid into the tracker.

> That's pretty much exactly what I think would be most useful.

I kinda wonder why the CF app doesn't work like that, actually.
(Yeah, I know the poor thread linking in the archives is an issue.)

			regards, tom lane

Re: Getting a bug tracker for the Postgres project

Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-05-31T14:21:36Z

"ktm@rice.edu" <ktm@rice.edu> wrote:
 
> maybe we can do some tweaking our search engine to improve it.
 
A custom dictionary to carefully add a few synonyms might go a long
way.  I often need to try a number of permutations of likely words
to get relevant hits.
 
Including the subject line in searches, with a higher weight than
message body text, would also be great.
 
Possibly it would help to be able to search on From or To fields
(including CC in the To).  Sometimes you have some recollection who
participated in a discussion, but can't find the magic terms to get
a small result set which includes the right discussion.
 
I really think some pretty minor tweaks in these areas would go a
very long way toward making the archive searches more useful.
 
-Kevin

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-31T14:28:33Z

On Tue, May 31, 2011 at 16:21, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> "ktm@rice.edu" <ktm@rice.edu> wrote:
>
>> maybe we can do some tweaking our search engine to improve it.
>
> A custom dictionary to carefully add a few synonyms might go a long
> way.  I often need to try a number of permutations of likely words
> to get relevant hits.

If you can provide one, please do :-)
Right now, all we have is:
postgres postgres
postgresql postgres
pgsql postgres
pg postgres
postgre postgres


> Including the subject line in searches, with a higher weight than
> message body text, would also be great.

We already do this - we set them to class "A" with setweight().


> Possibly it would help to be able to search on From or To fields
> (including CC in the To).  Sometimes you have some recollection who
> participated in a discussion, but can't find the magic terms to get
> a small result set which includes the right discussion.

This we don't do -w e store the From field, but we don't index it. And
we don't do anything with the To field.

So that's certainly something we could add.


> I really think some pretty minor tweaks in these areas would go a
> very long way toward making the archive searches more useful.

Any patches are definitely welcome - you can find the search system at
https://pgweb.postgresql.org/browser/trunk/portal/tools/search :-)

(for the archives, you're probably most interested in
classes/ArchiveIndexer.class.php and the sql/functions.sql file)

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

Re: Getting a bug tracker for the Postgres project

Joe Abbate <jma@freedomcircle.com> — 2011-05-31T14:43:07Z

On 05/31/2011 04:36 AM, Magnus Hagander wrote:
> So in order to start a brand new bikeshed to paint on, have we even
> considered a very trivial workflow like letting the bugtracker
> actually *only* track our existing lists and archives. That would
> mean:
> 
> * Mailing lists are *primary*, and the mailing list archives are
> *primary* (yes, this probably requires a fix to the archives, but that
> really is a different issue)
> * New bugs are added by simply saying "this messageid represents a
> thread that has this bug in it", and all the actual contents are
> pulled from the archives
> * On top of this, the bug just tracks metadata - such as open/closed
> more or less. It does *not* track the actual contents at all.
> * Bugs registered through the bugs form would of course automatically
> add such a messageid into the tracker.

I have a web crawler for a website I maintain that I could modify to
crawl through the archives of -bugs, say from 5 Dec 2003 where the first
bug with the new format appears, and capture the structured data
(reference, logged by, email address, PG version, OS, description, and
message URL) into a table, for every message whose subject starts with
"BUG #", and capture each message URL for any message that has "BUG #"
somewhere in the subject, in a second table.

I presume the tables could be used even if it's decided to go with
something like RT or BZ, but before I spend a couple of hours on this
I'd like see some ayes or nays.  Useful or not?

Joe

Re: Getting a bug tracker for the Postgres project

Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-05-31T15:02:49Z

Magnus Hagander <magnus@hagander.net> wrote:

> Any patches are definitely welcome - you can find the search
> system at
> https://pgweb.postgresql.org/browser/trunk/portal/tools/search
> :-)
> 
> (for the archives, you're probably most interested in
> classes/ArchiveIndexer.class.php and the sql/functions.sql file)

I stashed this away for future reference; I'll take a look when I
have a bit more free time.

I suppose the first thing is to search the archives for posts about
not being able to find some discussion in the archives, where
someone then provides search criteria or a link..  I know I've seen
a bunch of those -- I just hope I can find them...  ;-)

-Kevin

Re: Getting a bug tracker for the Postgres project

Kenneth Marshall <ktm@rice.edu> — 2011-05-31T15:04:28Z

On Tue, May 31, 2011 at 09:36:00AM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > On 05/31/2011 06:41 AM, Magnus Hagander wrote:
> >> We already have a search system that works reasonably well for the archives...
> 
> > I trust this weas a piece of sarcasm. I spoke to more than a few people 
> > at pgcon and nobody had a good word to say about the search system on 
> > the archives.
> 
> Please note, though, that there is no bug tracker anywhere whose search
> mechanism doesn't suck as much or more.  If you're unhappy with the
> search stuff the solution is to improve it, not bring in another bad
> mechanism.
> 
+1

Ken

Re: Getting a bug tracker for the Postgres project

Robert Haas <robertmhaas@gmail.com> — 2011-05-31T15:13:13Z

On Tue, May 31, 2011 at 9:59 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> On 05/31/2011 09:33 AM, Robert Haas wrote:
>>
>> IIRC, both of them think that you should log into the web interface to
>> send emails (which, in the case of Bugzilla, don't permit replies),
>> rather than sending emails that show up in the web interface.
>
> I think you probably need to look at Bugzilla again. Here's what the current
> feature page at <http://www.bugzilla.org/features/#email-in> says:
>
>   In addition to the web interface, you can send Bugzilla an email
>   that will create a new bug, or will modify an existing bug.

That's possible.  I haven't used it in about 5 years, and I suppose
that makes my opinion of it hideously dated.  I wouldn't like it if
someone judged PostgreSQL based on what 8.1 can do.

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

Re: Getting a bug tracker for the Postgres project

Robert Haas <robertmhaas@gmail.com> — 2011-05-31T15:14:02Z

On Tue, May 31, 2011 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> So in order to start a brand new bikeshed to paint on, have we even
>>> considered a very trivial workflow like letting the bugtracker
>>> actually *only* track our existing lists and archives. That would
>>> mean:
>>>
>>> * Mailing lists are *primary*, and the mailing list archives are
>>> *primary* (yes, this probably requires a fix to the archives, but that
>>> really is a different issue)
>>> * New bugs are added by simply saying "this messageid represents a
>>> thread that has this bug in it", and all the actual contents are
>>> pulled from the archives
>>> * On top of this, the bug just tracks metadata - such as open/closed
>>> more or less. It does *not* track the actual contents at all.
>>> * Bugs registered through the bugs form would of course automatically
>>> add such a messageid into the tracker.
>
>> That's pretty much exactly what I think would be most useful.
>
> I kinda wonder why the CF app doesn't work like that, actually.
> (Yeah, I know the poor thread linking in the archives is an issue.)

I thought this pretty much WAS how the CF app works, except that it's
for patches rather than bugs.  Perhaps it could be extended to also
track bugs...

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

Re: Getting a bug tracker for the Postgres project

Alvaro Herrera <alvherre@commandprompt.com> — 2011-05-31T15:38:16Z

Excerpts from Joe Abbate's message of mar may 31 10:43:07 -0400 2011:

> I have a web crawler for a website I maintain that I could modify to
> crawl through the archives of -bugs, say from 5 Dec 2003 where the first
> bug with the new format appears, and capture the structured data
> (reference, logged by, email address, PG version, OS, description, and
> message URL) into a table, for every message whose subject starts with
> "BUG #", and capture each message URL for any message that has "BUG #"
> somewhere in the subject, in a second table.
> 
> I presume the tables could be used even if it's decided to go with
> something like RT or BZ, but before I spend a couple of hours on this
> I'd like see some ayes or nays.  Useful or not?

I think this would be easier if you crawled the monthly mboxen instead
of the web archives.  It'd be preferable to use message-ids to identify
messages rather than year-and-month based URLs.

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

Re: Getting a bug tracker for the Postgres project

Tom Lane <tgl@sss.pgh.pa.us> — 2011-05-31T16:01:09Z

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 31, 2011 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I kinda wonder why the CF app doesn't work like that, actually.
>> (Yeah, I know the poor thread linking in the archives is an issue.)

> I thought this pretty much WAS how the CF app works, except that it's
> for patches rather than bugs.  Perhaps it could be extended to also
> track bugs...

Well, the point is you have to go and manually fool around with the web
interface to enter something into CF, rather than just cc'ing it on your
patch or review email.

			regards, tom lane

Re: Getting a bug tracker for the Postgres project

Robert Haas <robertmhaas@gmail.com> — 2011-05-31T16:07:46Z

On Tue, May 31, 2011 at 12:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, May 31, 2011 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I kinda wonder why the CF app doesn't work like that, actually.
>>> (Yeah, I know the poor thread linking in the archives is an issue.)
>
>> I thought this pretty much WAS how the CF app works, except that it's
>> for patches rather than bugs.  Perhaps it could be extended to also
>> track bugs...
>
> Well, the point is you have to go and manually fool around with the web
> interface to enter something into CF, rather than just cc'ing it on your
> patch or review email.

Oh, I see.  Well, that could probably be changed.  One thing to think
about with the current system is that typically only the most relevant
links get added, as opposed to the entire thread.  Now, the bad news
is that means things often don't get added at all.  The good news is
that typically when people do update it, the add only the relevant
things, thus avoiding filling it up with a massive amount of crap.  I
don't know whether that works out to a bug or a feature.

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

Re: Getting a bug tracker for the Postgres project

Joe Abbate <jma@freedomcircle.com> — 2011-05-31T16:09:27Z

Hola Alvaro,

On 05/31/2011 11:38 AM, Alvaro Herrera wrote:
> I think this would be easier if you crawled the monthly mboxen instead
> of the web archives.  It'd be preferable to use message-ids to identify
> messages rather than year-and-month based URLs.

I can capture the message-ids, as well as the message date, from
crawling the web archives.  If the tracker has some kind of web
interface, I assume a link such as

http://archives.postgresql.org/pgsql-bugs/2003-12/msg00046.php

would be easier to follow than

<20031205173035.GA16741@wolff.to>

unless the mboxes are stored in an easily accessible form by message-id
(i.e., outside the web archives).

Plus having the web link allows eventual tracking of messages outside of
-bugs.

Joe

Re: Getting a bug tracker for the Postgres project

Joshua D. Drake <jd@commandprompt.com> — 2011-05-31T16:32:43Z

On 05/31/2011 01:12 AM, Peter Eisentraut wrote:
> On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote:
>> I have used RT and I found that the
>> web interface was both difficult to use and unwieldly for tickets
>> containing large numbers of messages.  Maybe those those things have
>> been improved, but frankly if RT or Bugzilla is the best we can come
>> up with then I'd rather not have a bug tracker at all.
>
> Given that you have been one of the people calling for a bug tracker,
> and these are the two most widely used systems available, what's wrong
> with them and what else would you suggest?

Just FYI, CMD uses redmine and so far it is the best we have found. It 
isn't perfect certainly but overall it does a nice job. It supports 
email integration as well as plugins (we have even written a couple).

Alvaro has also brought up the system that Debian uses which is actually 
email based versus web based.

JD


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

Re: Getting a bug tracker for the Postgres project

Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-05-31T16:41:59Z

Joe Abbate <jma@freedomcircle.com> wrote:

> I assume a link such as
> 
> http://archives.postgresql.org/pgsql-bugs/2003-12/msg00046.php
> 
> would be easier to follow than
> 
> <20031205173035.GA16741@wolff.to>

The point is that the community seems to have reached a consensus
that they would rather use this URL for the above message:

http://archives.postgresql.org/message-id/20031205173035.GA16741@wolff.to

-Kevin

Re: Getting a bug tracker for the Postgres project

Alvaro Herrera <alvherre@commandprompt.com> — 2011-05-31T16:59:33Z

Excerpts from Kevin Grittner's message of mar may 31 12:41:59 -0400 2011:
> Joe Abbate <jma@freedomcircle.com> wrote:
>  
> > I assume a link such as
> > 
> > http://archives.postgresql.org/pgsql-bugs/2003-12/msg00046.php
> > 
> > would be easier to follow than
> > 
> > <20031205173035.GA16741@wolff.to>
>  
> The point is that the community seems to have reached a consensus
> that they would rather use this URL for the above message:
>  
> http://archives.postgresql.org/message-id/20031205173035.GA16741@wolff.to

Yeah, I keep dreaming that one day we will get rid of the silly monthly
partitioning of archives.  Those URLs will eventually be legacy --
existing ones will continue to work, but new messages will not (may not)
get them any longer.

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

Re: Getting a bug tracker for the Postgres project

Joe Abbate <jma@freedomcircle.com> — 2011-05-31T17:10:32Z

On 05/31/2011 12:41 PM, Kevin Grittner wrote:
> The point is that the community seems to have reached a consensus
> that they would rather use this URL for the above message:
>  
> http://archives.postgresql.org/message-id/20031205173035.GA16741@wolff.to

OK, as I said, I can still capture the message-id's by crawling -bugs by
year-month.

Joe

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-31T17:13:40Z

On Tue, May 31, 2011 at 19:10, Joe Abbate <jma@freedomcircle.com> wrote:
> On 05/31/2011 12:41 PM, Kevin Grittner wrote:
>> The point is that the community seems to have reached a consensus
>> that they would rather use this URL for the above message:
>>
>> http://archives.postgresql.org/message-id/20031205173035.GA16741@wolff.to
>
> OK, as I said, I can still capture the message-id's by crawling -bugs by
> year-month.

Just to be clear, crawling the current archives for this info is
probably the easiest part of the whole project. In fact, the majority
of the information you'd need is *already* in a postgresql database on
search.postgresql.org.

So - let's start in the other end, and get back to this if/when it's needed.

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

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-05-31T17:37:24Z

On tis, 2011-05-31 at 14:58 +0200, Magnus Hagander wrote:
> But sure, it can probably be improved. But what people are then
> basically asying is that tsearch isn't good enough for searching.

For one thing, there should be more structured search possibilities,
such as by date or author or subject only etc.  Nothing that tsearch has
anything to do with.

Re: Getting a bug tracker for the Postgres project

Simon Riggs <simon@2ndquadrant.com> — 2011-05-31T17:52:34Z

On Sun, May 29, 2011 at 4:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> That doesn't mean that better integration cannot be worked on later, but
>> this illusion that a bug tracker must have magical total awareness of
>> the entire flow of information in the project from day one is an
>> illusion and has blocked this business for too long IMO.
>
> If it has only a partial view of the set of bugs being worked on, it's
> not going to meet the goals that are being claimed for it.
>
> I don't doubt that somebody could run around and link every discussion
> about a bug into the tracker.  I'm just dubious that that actually
> *will* happen with enough reliability to make the tracker more useful
> than a mailing-list search.
>
> In the end, I think that requests for a tracker mostly come from people
> who are not part of this community, or at least not part of its mailing
> lists (which is about the same thing IMO).  If they submitted a bug
> report via the lists, they're generally going to get replies via email,
> and that seems sufficient to me.  But if they submitted a report via the
> web form, they might well be expecting that they can track what's going
> on with it on a web page.  And that's not unreasonable.  But we could
> fix that without any changes at all in our work processes.  Just have
> the webform add a "cc: bugbot-bugNNNN@postgresql.org" to each submitted
> email, and set up a bot to collect the traffic and display it on a
> suitable web page.  (Spam filtering left as an exercise for the reader.)


The part of the discussion we've missed so far is that bug trackers
are usually about the blame functionality and measurement of response
times.

We're a responsive and diligent community, so I see no problem here
that wouldn't be solved simply by using better static URLs.

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

Re: Getting a bug tracker for the Postgres project

Joe Abbate <jma@freedomcircle.com> — 2011-05-31T17:59:39Z

On 05/31/2011 01:13 PM, Magnus Hagander wrote:
> Just to be clear, crawling the current archives for this info is
> probably the easiest part of the whole project. In fact, the majority
> of the information you'd need is *already* in a postgresql database on
> search.postgresql.org.

Does that database have the bug number, PG version and OS as separate
columns, or is it simply an index over all the messages across all the
lists?  I think a table just of bug info would be useful at this time,
e.g., to load a potential candidate.  However, the message database --if
it includes the message bodies-- would obviously be easier to work with
than web crawling.

Joe

Re: Getting a bug tracker for the Postgres project

Alvaro Herrera <alvherre@commandprompt.com> — 2011-05-31T18:05:45Z

Excerpts from Joshua D. Drake's message of mar may 31 12:32:43 -0400 2011:

> > Given that you have been one of the people calling for a bug tracker,
> > and these are the two most widely used systems available, what's wrong
> > with them and what else would you suggest?
> 
> Just FYI, CMD uses redmine and so far it is the best we have found. It 
> isn't perfect certainly but overall it does a nice job. It supports 
> email integration as well as plugins (we have even written a couple).

I certainly wouldn't suggest that Redmine wouldn't cause a change in
workflow though.

> Alvaro has also brought up the system that Debian uses which is actually 
> email based versus web based.

Yeah, that's debbugs, which has been mentioned elsewhere in this thread.

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

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-31T18:13:43Z

On Tue, May 31, 2011 at 19:59, Joe Abbate <jma@freedomcircle.com> wrote:
> On 05/31/2011 01:13 PM, Magnus Hagander wrote:
>> Just to be clear, crawling the current archives for this info is
>> probably the easiest part of the whole project. In fact, the majority
>> of the information you'd need is *already* in a postgresql database on
>> search.postgresql.org.
>
> Does that database have the bug number, PG version and OS as separate
> columns, or is it simply an index over all the messages across all the
> lists?  I think a table just of bug info would be useful at this time,
> e.g., to load a potential candidate.  However, the message database --if
> it includes the message bodies-- would obviously be easier to work with
> than web crawling.

It does not have all those details, but it has the sender, subject and
bodies broken out. So it's definitely an easier starting point.

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

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-05-31T18:14:26Z

On Tue, May 31, 2011 at 19:37, Peter Eisentraut <peter_e@gmx.net> wrote:
> On tis, 2011-05-31 at 14:58 +0200, Magnus Hagander wrote:
>> But sure, it can probably be improved. But what people are then
>> basically asying is that tsearch isn't good enough for searching.
>
> For one thing, there should be more structured search possibilities,
> such as by date or author or subject only etc.  Nothing that tsearch has
> anything to do with.

All those sound like things that should be easily doable on top of the
current database. Care to create a wiki page with a suggested
interface? (Unless oyu want to code up an actual patch for it :P)


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

Re: Getting a bug tracker for the Postgres project

Joshua D. Drake <jd@commandprompt.com> — 2011-05-31T18:18:28Z

On 05/31/2011 11:05 AM, Alvaro Herrera wrote:
> Excerpts from Joshua D. Drake's message of mar may 31 12:32:43 -0400 2011:
>
>>> Given that you have been one of the people calling for a bug tracker,
>>> and these are the two most widely used systems available, what's wrong
>>> with them and what else would you suggest?
>>
>> Just FYI, CMD uses redmine and so far it is the best we have found. It
>> isn't perfect certainly but overall it does a nice job. It supports
>> email integration as well as plugins (we have even written a couple).
>
> I certainly wouldn't suggest that Redmine wouldn't cause a change in
> workflow though.

Nor am I, I was mainly bringing it up as a (better) alternative to 
bugzilla and rt.

Sincerely,

Joshua D. Drake


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

Re: Getting a bug tracker for the Postgres project

Cédric Villemain <cedric.villemain.debian@gmail.com> — 2011-05-31T18:52:54Z

2011/5/31 Alvaro Herrera <alvherre@commandprompt.com>:
> Excerpts from Joshua D. Drake's message of mar may 31 12:32:43 -0400 2011:
>> Alvaro has also brought up the system that Debian uses which is actually
>> email based versus web based.
>
> Yeah, that's debbugs, which has been mentioned elsewhere in this thread.

I like this one, does it have something we don't like ?
it is mail oriented, have a web-interface, a search engine. It is easy
to merge bugs etc... The other alternative more individual is a sieve
script to filter and manage -bugs and -commiters maybe -hackers (not
done, but that might not be so hard)

>
> --
> Álvaro Herrera <alvherre@commandprompt.com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



-- 
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

Re: Getting a bug tracker for the Postgres project

Dimitri Fontaine <dimitri@2ndquadrant.fr> — 2011-05-31T20:11:35Z

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Kevin Grittner's message of mar may 31 12:41:59 -0400 2011:
>> The point is that the community seems to have reached a consensus
>> that they would rather use this URL for the above message:
>>  
>> http://archives.postgresql.org/message-id/20031205173035.GA16741@wolff.to
>
> Yeah, I keep dreaming that one day we will get rid of the silly monthly
> partitioning of archives.  Those URLs will eventually be legacy --
> existing ones will continue to work, but new messages will not (may not)
> get them any longer.

Check out the following POC, which needs to get migrated into a django
application for the upcoming new infrastructure:

  http://archives.beccati.org/

It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL
database.  The mails threading view is even a CTE.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

Re: Getting a bug tracker for the Postgres project

Josh Berkus <josh@agliodbs.com> — 2011-05-31T21:05:23Z

All,

Let me mention some of the reasons we as a project could use a bug
tracker which have nothing to do with actually fixing bugs.

(1) Testing: a bug tracker could be used for beta testing instead of the
ad-hoc system I'm writing.  Assuming it has the right features, of course.

(2) User information: right now, if a user has an issue, it's very very
hard for them to answer the question "Has this already been reported
and/or fixed in a later release."  This is a strong source of
frustration for business users who don't actively participate in the
community, a complaint I have heard multiple times.

(3) Lack of a bug tracker with a web services API prevents downstream
projects (PostGIS, RHEL, Ubuntu, Django, Drupal, etc.) from linking in
PostgreSQL bug reports which affect their users.  Also, because these
projects are used to bug trackers, they get confused when they need to
report a bug to us.

(4) Because having a bug tracker is seen as standard and mainstream
among OSS projects, the fact that we don't have one is regarded as
oddball and backwards, and does result in some companies choosing not to
use PostgreSQL because we're perceived as "too weird" and
"anti-commercial".

Where *fixing* bugs is concerned, I'm concerned that a bug tracker would
actually slow things down.  I'm dubious about our ability to mobilize
volunteers for anything other than bug triage, and the fact that we
*don't* triage is an advantage in bug report responsiveness (I have
"unconfirmed" bugs for Thunderbird which have been pending for 3 years).
 So I'm skeptical about bug trackers on that score.

However, for the four non-fixing items, having some kind of bug tracker
would be a real asset to the project.  I'm just not sure what kind of
bug tracker that would be.

BTW, we talked to Debian about debbugs ages ago, and the Debian project
said that far too much of debbugs was not portable to other projects.

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

Re: Getting a bug tracker for the Postgres project

Alvaro Herrera <alvherre@commandprompt.com> — 2011-05-31T21:31:53Z

Excerpts from Dimitri Fontaine's message of mar may 31 16:11:35 -0400 2011:

> Check out the following POC, which needs to get migrated into a django
> application for the upcoming new infrastructure:
> 
>   http://archives.beccati.org/
> 
> It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL
> database.  The mails threading view is even a CTE.

Yeah, it's great.  Last time I heard, though, Mateo wasn't open to doing
any more work on it (including fixing a bunch of bugs we found) until
the web migration to the Django stuff materialized.

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

Re: Getting a bug tracker for the Postgres project

Alvaro Herrera <alvherre@commandprompt.com> — 2011-05-31T21:41:25Z

Excerpts from Josh Berkus's message of mar may 31 17:05:23 -0400 2011:

> BTW, we talked to Debian about debbugs ages ago, and the Debian project
> said that far too much of debbugs was not portable to other projects.

The good news is that the GNU folk proved them wrong, as evidenced
elsewhere in the thread.

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

Re: Getting a bug tracker for the Postgres project

Cédric Villemain <cedric.villemain.debian@gmail.com> — 2011-05-31T21:50:58Z

2011/5/31 Josh Berkus <josh@agliodbs.com>:
> All,
>
> Let me mention some of the reasons we as a project could use a bug
> tracker which have nothing to do with actually fixing bugs.
>
> (1) Testing: a bug tracker could be used for beta testing instead of the
> ad-hoc system I'm writing.  Assuming it has the right features, of course.
>
> (2) User information: right now, if a user has an issue, it's very very
> hard for them to answer the question "Has this already been reported
> and/or fixed in a later release."  This is a strong source of
> frustration for business users who don't actively participate in the
> community, a complaint I have heard multiple times.
>
> (3) Lack of a bug tracker with a web services API prevents downstream
> projects (PostGIS, RHEL, Ubuntu, Django, Drupal, etc.) from linking in
> PostgreSQL bug reports which affect their users.  Also, because these
> projects are used to bug trackers, they get confused when they need to
> report a bug to us.
>
> (4) Because having a bug tracker is seen as standard and mainstream
> among OSS projects, the fact that we don't have one is regarded as
> oddball and backwards, and does result in some companies choosing not to
> use PostgreSQL because we're perceived as "too weird" and
> "anti-commercial".
>
> Where *fixing* bugs is concerned, I'm concerned that a bug tracker would
> actually slow things down.  I'm dubious about our ability to mobilize
> volunteers for anything other than bug triage, and the fact that we
> *don't* triage is an advantage in bug report responsiveness (I have
> "unconfirmed" bugs for Thunderbird which have been pending for 3 years).
>  So I'm skeptical about bug trackers on that score.
>
> However, for the four non-fixing items, having some kind of bug tracker
> would be a real asset to the project.  I'm just not sure what kind of
> bug tracker that would be.
>
> BTW, we talked to Debian about debbugs ages ago, and the Debian project
> said that far too much of debbugs was not portable to other projects.

GNU succeed to use it, it seems:

http://debbugs.gnu.org/Using.html
http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1

>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



-- 
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-06-01T04:24:31Z

On tis, 2011-05-31 at 11:49 +0300, Peter Eisentraut wrote:
> On mån, 2011-05-30 at 01:30 -0400, Greg Smith wrote:
> > Greg Stark is right that Debbugs has a lot of interesting features 
> > similar to the desired workflow here.  It's not tied to just Debian 
> > anymore; the GNU project is also using it now. 
> 
> For the benefit of others, I suppose you are referring to this:
> http://debbugs.gnu.org/
> 
> This is actually pretty exciting news, as it alleviates the main concern
> with debbugs, that's is in practice impossible to use outside of Debian.
> (The other nice thing is that those GNU projects have also been lacking
> a good bug tracker in the past.)
> 
> Should we find the people behind this project and ask them to share some
> experiences?

Done that; I'll report back.

Re: Getting a bug tracker for the Postgres project

Dimitri Fontaine <dimitri@2ndquadrant.fr> — 2011-06-01T08:43:41Z

Alvaro Herrera <alvherre@commandprompt.com> writes:
>>   http://archives.beccati.org/
>> 
>> It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL
>> database.  The mails threading view is even a CTE.
>
> Yeah, it's great.  Last time I heard, though, Mateo wasn't open to doing
> any more work on it (including fixing a bunch of bugs we found) until
> the web migration to the Django stuff materialized.

Yeah, given the amount of work that already went into this prototype, I
guess I would have reacted about the same.  I'm not sure that's the only
project stuck behind the new platform migration.  How can we help with
this new infrastructure thing ?

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

Re: Getting a bug tracker for the Postgres project

Magnus Hagander <magnus@hagander.net> — 2011-06-01T08:53:17Z

On Wed, Jun 1, 2011 at 10:43, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>>>   http://archives.beccati.org/
>>>
>>> It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL
>>> database.  The mails threading view is even a CTE.
>>
>> Yeah, it's great.  Last time I heard, though, Mateo wasn't open to doing
>> any more work on it (including fixing a bunch of bugs we found) until
>> the web migration to the Django stuff materialized.
>
> Yeah, given the amount of work that already went into this prototype, I
> guess I would have reacted about the same.  I'm not sure that's the only
> project stuck behind the new platform migration.  How can we help with
> this new infrastructure thing ?

Actually, given a new box deployed by stefan just two or three days
ago, the infrastructure side is ready.

What would help at this point would be if at least one oft he *many*
different people who promised to do some code review on the new
website code would, you know, actually do that. (git.postgresql.org,
project pgweb and pgweb-static for those interested) And of course,
code improvements, not just review, is also always welcome.

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

Re: Getting a bug tracker for the Postgres project

Greg Smith <greg@2ndquadrant.com> — 2011-06-01T10:09:56Z

On 05/31/2011 05:41 PM, Alvaro Herrera wrote:
> Excerpts from Josh Berkus's message of mar may 31 17:05:23 -0400 2011:
>
>    
>> BTW, we talked to Debian about debbugs ages ago, and the Debian project
>> said that far too much of debbugs was not portable to other projects.
>>      
> The good news is that the GNU folk proved them wrong, as evidenced
> elsewhere in the thread.
>    

What happened is that one of the authors got motivated (not sure 
why/how) to put a major amount of work into making the code portable so 
that sites other than Debian could use it.  So past perceptions about it 
being really hard were correct, that's just been fixed since then.

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

Re: Getting a bug tracker for the Postgres project

Bruce Momjian <bruce@momjian.us> — 2011-06-03T20:31:49Z

Josh Berkus wrote:
> All,
> 
> Let me mention some of the reasons we as a project could use a bug
> tracker which have nothing to do with actually fixing bugs.
> 
> (1) Testing: a bug tracker could be used for beta testing instead of the
> ad-hoc system I'm writing.  Assuming it has the right features, of course.
> 
> (2) User information: right now, if a user has an issue, it's very very
> hard for them to answer the question "Has this already been reported
> and/or fixed in a later release."  This is a strong source of
> frustration for business users who don't actively participate in the
> community, a complaint I have heard multiple times.

Also, bug reporters frequently don't get any email feedback on when
their bug was fixed.  It is also hard to identify what major/minor
release fixed a specific bug, especially if the bug was rare.

> Where *fixing* bugs is concerned, I'm concerned that a bug tracker would
> actually slow things down.  I'm dubious about our ability to mobilize
> volunteers for anything other than bug triage, and the fact that we
> *don't* triage is an advantage in bug report responsiveness (I have
> "unconfirmed" bugs for Thunderbird which have been pending for 3 years).
>  So I'm skeptical about bug trackers on that score.

Yes, I agree.  Too many bug systems are just a dumping-pile for bugs.

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

  + It's impossible for everything to be true. +

Re: Getting a bug tracker for the Postgres project

Bruce Momjian <bruce@momjian.us> — 2011-06-03T20:35:14Z

Greg Stark wrote:
> On Mon, May 30, 2011 at 6:52 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > ?The number of people reading and replying to
> > emails on pgsql-bugs is already insufficient, perhaps because of the
> > (incorrect) perception that Tom does or will fix everything and no one
> > else needs to care. ?So anything that makes it harder for people to
> > follow along and participate is a non-starter IMV.
> 
> Actually I think most of our bugs don't come in from pgsql-bugs. I
> think we want to add other bugs that come up from discussions on
> -hackers or -general which for whatever reason don't get immediately
> fixed.

Agreed.  At that point the TODO list is no longer needed, perhaps.  It
would be nice to have a system where we could categorize items, and add
"features" as well because the bug/feature distinction is often very
hard to make.

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

  + It's impossible for everything to be true. +

Re: Getting a bug tracker for the Postgres project

Bruce Momjian <bruce@momjian.us> — 2011-06-03T20:36:30Z

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > That doesn't mean that better integration cannot be worked on later, but
> > this illusion that a bug tracker must have magical total awareness of
> > the entire flow of information in the project from day one is an
> > illusion and has blocked this business for too long IMO.
> 
> If it has only a partial view of the set of bugs being worked on, it's
> not going to meet the goals that are being claimed for it.

The problem with a bug tracker that only tracks some bugs is that people
will mistakenly believe the system is complete, when it is not.

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

  + It's impossible for everything to be true. +

Re: Getting a bug tracker for the Postgres project

Bruce Momjian <bruce@momjian.us> — 2011-06-03T20:42:05Z

Just to throw out a crazy idea, there has been talk of bug ids.  What if
a thread, made up of multiple message ids, was in fact the bug id, and
the first message in the thread (ignoring month boundaries) was the
definitive bug id, but any of the message ids could be used to represent
the definitive one.

That way, a message id mentioned in a commit message could track back to
the definitive bug id and therefore be used to close the bug.

If you think of it that way, your email stream is just a stream of
threads, with a definitive bug id per thread, that is either "not a
bug", "a bug", " a fix", or "other".

In a way, all you need to do is for someone to add the "thread" to the
bug system via email, and change its status via email.

Yes, crazy, but that is kind of how I track open items in my mailbox.

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

  + It's impossible for everything to be true. +

Re: Getting a bug tracker for the Postgres project

Peter Eisentraut <peter_e@gmx.net> — 2011-06-03T21:23:03Z

On fre, 2011-06-03 at 16:42 -0400, Bruce Momjian wrote:
> Just to throw out a crazy idea, there has been talk of bug ids.  What
> if a thread, made up of multiple message ids, was in fact the bug id,
> and the first message in the thread (ignoring month boundaries) was
> the definitive bug id, but any of the message ids could be used to
> represent the definitive one.

That way, if someone breaks a thread, you can't reattach the
conversation to a bug.  And you couldn't take a thread off a bug or to a
new bug.

A heavily email-based tracker such as debbugs works almost like that,
but for those mentioned reasons, it's simpler to have the messages
belonging to a bug stored separately.

Re: Getting a bug tracker for the Postgres project

Christopher Browne <cbbrowne@gmail.com> — 2011-06-03T21:33:02Z

On Fri, Jun 3, 2011 at 8:42 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Just to throw out a crazy idea, there has been talk of bug ids.  What if
> a thread, made up of multiple message ids, was in fact the bug id, and
> the first message in the thread (ignoring month boundaries) was the
> definitive bug id, but any of the message ids could be used to represent
> the definitive one.
>
> That way, a message id mentioned in a commit message could track back to
> the definitive bug id and therefore be used to close the bug.
>
> If you think of it that way, your email stream is just a stream of
> threads, with a definitive bug id per thread, that is either "not a
> bug", "a bug", " a fix", or "other".
>
> In a way, all you need to do is for someone to add the "thread" to the
> bug system via email, and change its status via email.
>
> Yes, crazy, but that is kind of how I track open items in my mailbox.

That doesn't seem crazy at all...  It seems to parallel the way that
distributed SCMs treat series of versions as the intersections of
related repository versions, each identified by a hash code.

There is one problem I see with the "definitive bug ID," which is that
a thread might wind up discussing *two* problems, and it would be
regrettable to discover that this got forced to be treated as a single
bug.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"