Getting a bug tracker for the Postgres project

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

On 05/27/2011 08:36 AM, MauMau wrote:
> Hello,
>
> I posted a patch for bug #6011 to pgsql-hackers several days ago. How
> can I check the status of bug fixes? I'm worried that the patch might
> be forgotten, because bug #5842 was missed for two months until Bruce
> noticed it.
>
>

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

cheers

andrew

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

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

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

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

On 05/27/2011 05:36 AM, MauMau wrote:
> Hello,
>
> I posted a patch for bug #6011 to pgsql-hackers several days ago. How
> can I check the status of bug fixes? I'm worried that the patch might be
> forgotten, because bug #5842 was missed for two months until Bruce
> noticed it.

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

Yes, it is a long standing argument.

Yes, it is ridiculous.

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

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

Sincerely,

Joshua D. Drake

>
> Regards
> MauMau
>
>

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

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> You have done what you need to do to check the status. Someone who knows
> something about the bug should speak up at some point.

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

regards, tom lane

On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> You have done what you need to do to check the status. Someone who knows
>> something about the bug should speak up at some point.
>
> That patch is waiting for a committer who knows something about Windows
> to pick it up.

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

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

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

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> That patch is waiting for a committer who knows something about Windows
>> to pick it up.

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

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

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

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

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

regards, tom lane

On Fri, May 27, 2011 at 2:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> That patch is waiting for a committer who knows something about Windows
>>> to pick it up.
>
>> It might be useful, in this situation, for the OP to add this patch to
>> the CommitFest application.
>
>> https://commitfest.postgresql.org/action/commitfest_view/open
>
>> Also, I think it's about time we got ourselves some kind of bug
>> tracker.
>
> [ shrug... ]  I think the main problem is a lack of committer cycles.
> If so, the extra bureaucracy involved in managing a bug tracker will
> make things worse, not better.
>
> However, if someone *else* wants to do the work of entering bugs into a
> tracker and updating their status, far be it from me to stand in their
> way.

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

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

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

On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:
> Also, I think it's about time we got ourselves some kind of bug
> tracker. I have no idea how to make that work without breaking
> workflow that works now, but a quick survey of my pgsql-bugs email
> suggests that this is far from the only thing slipping through the
> cracks.

The problem is finding a usable bug tracking software.

On Friday, May 27, 2011 20:39:26 Robert Haas wrote:
> On Fri, May 27, 2011 at 2:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>> That patch is waiting for a committer who knows something about Windows
> >>> to pick it up.
> >>
> >> It might be useful, in this situation, for the OP to add this patch to
> >> the CommitFest application.
> >>
> >> https://commitfest.postgresql.org/action/commitfest_view/open
> >>
> >> Also, I think it's about time we got ourselves some kind of bug
> >> tracker.
> >
> > [ shrug... ] I think the main problem is a lack of committer cycles.
> > If so, the extra bureaucracy involved in managing a bug tracker will
> > make things worse, not better.
> >
> > However, if someone *else* wants to do the work of entering bugs into a
> > tracker and updating their status, far be it from me to stand in their
> > way.
> And who is to say only committers can fix bugs? Actually commit the
> fixes themselves, yes. Write the patches? No.
If I see a bug in a region I know something about and its on a platform I care
about (i.e. likely only linux) I try to do this. But its hard, in most
situations one of you already did it. Tom and you are just to goddamn fast in
many, many cases. Which is totally great, don't get me wrong, but makes it
hard to beat you as a mere mortal ;)

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

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

Andres

On Fri, May 27, 2011 at 9:24 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:
>> Also, I think it's about time we got ourselves some kind of bug
>> tracker.  I have no idea how to make that work without breaking
>> workflow that works now, but a quick survey of my pgsql-bugs email
>> suggests that this is far from the only thing slipping through the
>> cracks.
>
> The problem is finding a usable bug tracking software.

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

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

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

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

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

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

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

From: "Peter Eisentraut" <peter_e(at)gmx(dot)net>
> On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:
>> Also, I think it's about time we got ourselves some kind of bug
>> tracker. I have no idea how to make that work without breaking
>> workflow that works now, but a quick survey of my pgsql-bugs email
>> suggests that this is far from the only thing slipping through the
>> cracks.
>
> The problem is finding a usable bug tracking software.

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

Regards
MauMau

On 05/28/2011 05:47 AM, MauMau wrote:
> From: "Peter Eisentraut" <peter_e(at)gmx(dot)net>
>> On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:
>>> Also, I think it's about time we got ourselves some kind of bug
>>> tracker. I have no idea how to make that work without breaking
>>> workflow that works now, but a quick survey of my pgsql-bugs email
>>> suggests that this is far from the only thing slipping through the
>>> cracks.
>>
>> The problem is finding a usable bug tracking software.
>
> I think JIRA is very good. Almost all projects in Apache Software
> Foundation (ASF) including Tomcat, Hadoop, Apache HTTP server, use JIRA.
> With JIRA, we can know various counts such as the number of bugs per
> major/minor release, not-fixed bugs, new features in each major release,

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

Stefan

On 05/27/2011 07:55 PM, Robert Haas wrote:
> On Fri, May 27, 2011 at 12:21 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "Joshua D. Drake"<jd(at)commandprompt(dot)com> writes:
>>> You have done what you need to do to check the status. Someone who knows
>>> something about the bug should speak up at some point.
>>
>> That patch is waiting for a committer who knows something about Windows
>> to pick it up.
>
> It might be useful, in this situation, for the OP to add this patch to
> the CommitFest application.
>
> https://commitfest.postgresql.org/action/commitfest_view/open
>
> Also, I think it's about time we got ourselves some kind of bug
> tracker. I have no idea how to make that work without breaking
> workflow that works now, but a quick survey of my pgsql-bugs email
> suggests that this is far from the only thing slipping through the
> cracks.

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

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

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

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

Stefan

On Sat, May 28, 2011 at 10:02 AM, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)cc> wrote:
> well as for just keeping track of -bugs I guess a very simple schema would
> go pretty far:
>
> * have some tool monitor the list and if it sees a new bug# make it a
> ticket/bugreport

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

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

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

On 05/28/2011 12:19 PM, Dave Page wrote:
> On Sat, May 28, 2011 at 10:02 AM, Stefan Kaltenbrunner
> <stefan(at)kaltenbrunner(dot)cc> wrote:
>> well as for just keeping track of -bugs I guess a very simple schema would
>> go pretty far:
>>
>> * have some tool monitor the list and if it sees a new bug# make it a
>> ticket/bugreport
>
> The bug numbers come from a database backed web form anyway - seems it
> would be a lot easier to just have that script write a record to a
> table.

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

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

Stefan

On Fri, May 27, 2011 at 5:54 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> If I see a bug in a region I know something about and its on a platform I care
> about (i.e. likely only linux) I try to do this. But its hard, in most
> situations one of you already did it. Tom and you are just to goddamn fast in
> many, many cases. Which is totally great, don't get me wrong, but makes it
> hard to beat you as a mere mortal ;)

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

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

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

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

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

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

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

to:

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

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

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

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

On 05/27/2011 08:36 AM, MauMau wrote:
> I posted a patch for bug #6011 to pgsql-hackers several days ago. How
> can I check the status of bug fixes? I'm worried that the patch might
> be forgotten, because bug #5842 was missed for two months until Bruce
> noticed it.

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

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

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

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

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

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

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

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

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

* Runs on Postgres
* Has an email interface

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

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

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

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

On Sat, May 28, 2011 at 11:23 PM, Greg Sabino Mullane <greg(at)turnstep(dot)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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, May 28, 2011 at 11:23 PM, Greg Sabino Mullane <greg(at)turnstep(dot)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

On Sun, May 29, 2011 at 12:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

On 29 May 2011 14:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

Brendan Jurd <direvus(at)gmail(dot)com> writes:
> On 29 May 2011 14:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

On 05/29/2011 06:04 AM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sat, May 28, 2011 at 11:23 PM, Greg Sabino Mullane <greg(at)turnstep(dot)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

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.

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.

Peter Eisentraut <peter_e(at)gmx(dot)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(at)postgresql(dot)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

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(at)postgresql(dot)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

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(at)postgresql(dot)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

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

On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma(at)freedomcircle(dot)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(at)bugs(dot)debian(dot)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

Hi Greg,

On 05/29/2011 10:26 PM, Greg Stark wrote:
> On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma(at)freedomcircle(dot)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(at)bugs(dot)debian(dot)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

On 05/30/2011 04:26 AM, Greg Stark wrote:
> On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma(at)freedomcircle(dot)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(at)bugs(dot)debian(dot)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

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

On Sun, May 29, 2011 at 10:09 PM, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)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

On Mon, May 30, 2011 at 04:26, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma(at)freedomcircle(dot)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(at)bugs(dot)debian(dot)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/

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

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(at)bugs(dot)debian(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

On Mon, May 30, 2011 at 16:52, Joe Abbate <jma(at)freedomcircle(dot)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/

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

On Mon, May 30, 2011 at 2:26 AM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma(at)freedomcircle(dot)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(at)bugs(dot)debian(dot)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(at)bugs(dot)postgresql(dot)org" (or similar).
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

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.

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?

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

On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e(at)gmx(dot)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.

On Mon, May 30, 2011 at 8:16 PM, Christopher Browne <cbbrowne(at)gmail(dot)com> wrote:
> On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e(at)gmx(dot)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

On 31 May 2011 11:52, Robert Haas <robertmhaas(at)gmail(dot)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

Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
> On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e(at)gmx(dot)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

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(at)gmail(dot)com> wrote:
> > On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e(at)gmx(dot)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

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

On Mon, May 30, 2011 at 6:52 PM, Robert Haas <robertmhaas(at)gmail(dot)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

Kim Bisgaard <kim+pg(at)alleroedderne(dot)adsl(dot)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

On 05/31/2011 05:42 AM, Tom Lane wrote:
> Kim Bisgaard <kim+pg(at)alleroedderne(dot)adsl(dot)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(at)tracker(dot)postgresql(dot)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

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?

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.

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.

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?

On Mon, May 30, 2011 at 07:42, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Sun, May 29, 2011 at 10:09 PM, Stefan Kaltenbrunner
> <stefan(at)kaltenbrunner(dot)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/

On Tue, May 31, 2011 at 07:08, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)cc> wrote:
> On 05/31/2011 05:42 AM, Tom Lane wrote:
>> Kim Bisgaard <kim+pg(at)alleroedderne(dot)adsl(dot)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(at)tracker(dot)postgresql(dot)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/

On mån, 2011-05-30 at 22:17 -0400, Tom Lane wrote:
> Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
> > On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e(at)gmx(dot)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.

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?

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.

On Tue, May 31, 2011 at 11:47, Peter Eisentraut <peter_e(at)gmx(dot)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/

From: "Robert Haas" <robertmhaas(at)gmail(dot)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(at)2ndQuadrant(dot)com> wrote in message
news:4DE1A8E7(dot)1030601(at)2ndQuadrant(dot)com(dot)(dot)(dot)
> 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

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

On Tue, May 31, 2011 at 14:44, Andrew Dunstan <andrew(at)dunslane(dot)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/

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

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.

On Tue, May 31, 2011 at 15:07, Andrew Dunstan <andrew(at)dunslane(dot)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/

On Tue, May 31, 2011 at 02:58:02PM +0200, Magnus Hagander wrote:
> On Tue, May 31, 2011 at 14:44, Andrew Dunstan <andrew(at)dunslane(dot)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

On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut <peter_e(at)gmx(dot)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

On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus(at)hagander(dot)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

Andrew Dunstan <andrew(at)dunslane(dot)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

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(at)gmx(dot)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

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus(at)hagander(dot)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

"ktm(at)rice(dot)edu" <ktm(at)rice(dot)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

On Tue, May 31, 2011 at 16:21, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> "ktm(at)rice(dot)edu" <ktm(at)rice(dot)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/

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

Magnus Hagander <magnus(at)hagander(dot)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

On Tue, May 31, 2011 at 09:36:00AM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

On Tue, May 31, 2011 at 9:59 AM, Andrew Dunstan <andrew(at)dunslane(dot)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

On Tue, May 31, 2011 at 10:02 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus(at)hagander(dot)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

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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, May 31, 2011 at 10:02 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

On Tue, May 31, 2011 at 12:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, May 31, 2011 at 10:02 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

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(dot)GA16741(at)wolff(dot)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

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

Joe Abbate <jma(at)freedomcircle(dot)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(dot)GA16741(at)wolff(dot)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

Excerpts from Kevin Grittner's message of mar may 31 12:41:59 -0400 2011:
> Joe Abbate <jma(at)freedomcircle(dot)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(dot)GA16741(at)wolff(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

On Tue, May 31, 2011 at 19:10, Joe Abbate <jma(at)freedomcircle(dot)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/

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.

On Sun, May 29, 2011 at 4:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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(at)postgresql(dot)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

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

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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Tue, May 31, 2011 at 19:59, Joe Abbate <jma(at)freedomcircle(dot)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/

On Tue, May 31, 2011 at 19:37, Peter Eisentraut <peter_e(at)gmx(dot)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/

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

2011/5/31 Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)commandprompt(dot)com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)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

Alvaro Herrera <alvherre(at)commandprompt(dot)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

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

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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

2011/5/31 Josh Berkus <josh(at)agliodbs(dot)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(at)postgresql(dot)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

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.

Alvaro Herrera <alvherre(at)commandprompt(dot)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

On Wed, Jun 1, 2011 at 10:43, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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/

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Greg Stark wrote:
> On Mon, May 30, 2011 at 6:52 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

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.

On Fri, Jun 3, 2011 at 8:42 PM, Bruce Momjian <bruce(at)momjian(dot)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?"