Thread: How can I check the treatment of bug fixes?
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@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 05/27/2011 05:36 AM, MauMau wrote: > Hello, > > I posted a patch for bug #6011 to pgsql-hackers several days ago. How > can I check the status of bug fixes? I'm worried that the patch might be > forgotten, because bug #5842 was missed for two months until Bruce > noticed it. The joke that my lovely colleagues are not letting you in on is, "PostgreSQL does not believe in using a bug tracker". I personally think that some of us are still holding on to a strange and irrational premise that a bug tracker will somehow force the community to subjigate itself to "the man" and therefore we just can't allow it. Yes, it is a long standing argument. Yes, it is ridiculous. Yes, it is something that MySQL gets to make fun of us about (inside joke). You have done what you need to do to check the status. Someone who knows something about the bug should speak up at some point. Sincerely, Joshua D. Drake > > Regards > MauMau > > -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
"Joshua D. Drake" <jd@commandprompt.com> writes:
> You have done what you need to do to check the status. Someone who knows
> something about the bug should speak up at some point.
That patch is waiting for a committer who knows something about Windows
to pick it up.
regards, tom lane
On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> You have done what you need to do to check the status. Someone who knows >> something about the bug should speak up at some point. > > That patch is waiting for a committer who knows something about Windows > to pick it up. It might be useful, in this situation, for the OP to add this patch to the CommitFest application. https://commitfest.postgresql.org/action/commitfest_view/open Also, I think it's about time we got ourselves some kind of bug tracker. I have no idea how to make that work without breaking workflow that works now, but a quick survey of my pgsql-bugs email suggests that this is far from the only thing slipping through the cracks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> That patch is waiting for a committer who knows something about Windows >> to pick it up. > It might be useful, in this situation, for the OP to add this patch to > the CommitFest application. > https://commitfest.postgresql.org/action/commitfest_view/open > Also, I think it's about time we got ourselves some kind of bug > tracker. [ shrug... ] I think the main problem is a lack of committer cycles. If so, the extra bureaucracy involved in managing a bug tracker will make things worse, not better. However, if someone *else* wants to do the work of entering bugs into a tracker and updating their status, far be it from me to stand in their way. regards, tom lane
On Fri, May 27, 2011 at 2:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> That patch is waiting for a committer who knows something about Windows >>> to pick it up. > >> It might be useful, in this situation, for the OP to add this patch to >> the CommitFest application. > >> https://commitfest.postgresql.org/action/commitfest_view/open > >> Also, I think it's about time we got ourselves some kind of bug >> tracker. > > [ shrug... ] I think the main problem is a lack of committer cycles. > If so, the extra bureaucracy involved in managing a bug tracker will > make things worse, not better. > > However, if someone *else* wants to do the work of entering bugs into a > tracker and updating their status, far be it from me to stand in their > way. Definitely something to think about. But I think lack of committer bandwidth is only part of the problem. If someone had a free day tomorrow and wanted to flip through all the bugs that haven't had a response and address the ones they knew something about, how would they get a list? And who is to say only committers can fix bugs? Actually commit the fixes themselves, yes. Write the patches? No. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote: > Also, I think it's about time we got ourselves some kind of bug > tracker. I have no idea how to make that work without breaking > workflow that works now, but a quick survey of my pgsql-bugs email > suggests that this is far from the only thing slipping through the > cracks. The problem is finding a usable bug tracking software.
On Friday, May 27, 2011 20:39:26 Robert Haas wrote: > On Fri, May 27, 2011 at 2:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> On Fri, May 27, 2011 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> That patch is waiting for a committer who knows something about Windows > >>> to pick it up. > >> > >> It might be useful, in this situation, for the OP to add this patch to > >> the CommitFest application. > >> > >> https://commitfest.postgresql.org/action/commitfest_view/open > >> > >> Also, I think it's about time we got ourselves some kind of bug > >> tracker. > > > > [ shrug... ] I think the main problem is a lack of committer cycles. > > If so, the extra bureaucracy involved in managing a bug tracker will > > make things worse, not better. > > > > However, if someone *else* wants to do the work of entering bugs into a > > tracker and updating their status, far be it from me to stand in their > > way. > And who is to say only committers can fix bugs? Actually commit the > fixes themselves, yes. Write the patches? No. If I see a bug in a region I know something about and its on a platform I care about (i.e. likely only linux) I try to do this. But its hard, in most situations one of you already did it. Tom and you are just to goddamn fast in many, many cases. Which is totally great, don't get me wrong, but makes it hard to beat you as a mere mortal ;) Do you like separate patches for the back branches or is that basically useless work? Related to doing stuff like that is that I really find it hard to write a patch that happens to be liked by Tom or you so it does not have to be mostly rewritten. For that to change for one I would like to have the Coding Style to be expanded because I think there are loads of rules that exist only in bits and bits on the mailing lists. For another I would like to get a patch back instead of rewritten because without knowing the individual reasons for the changes its sometimes rather hard to know what the reason for a specific change was. I do realize thats quite a bit of work for you which is why I hesitated writing that... Andres
On Fri, May 27, 2011 at 9:24 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote: >> Also, I think it's about time we got ourselves some kind of bug >> tracker. I have no idea how to make that work without breaking >> workflow that works now, but a quick survey of my pgsql-bugs email >> suggests that this is far from the only thing slipping through the >> cracks. > > The problem is finding a usable bug tracking software. On the "upside," we have gotten to the point where people that count are finding the CommitFest application, which Is Not Simply Email, to be an acceptable and useful thing to use. But I don't find that I notably *like* any of the bug trackers that I have encountered thus far. There are a few "PG-basable" options (e.g. - RT, Bugzilla), but it's not *quite* good enough to pick something just because it's running on our own DB. I suspect that, from a technical perspective, the emergence of distributed bug trackers (Fossil, SD, Bugs Everywhere), which parallels distributed SCM (e.g. - Git) may be part of the "way to go," but that's still pointing at technical mechanism, as opposed to workflow. There is a page on the wiki documenting requirements that have been discussed: http://wiki.postgresql.org/wiki/TrackerDiscussion It hasn't been touched since 2008, but I expect that wiki page would make a better starting point to restart discussion than anything else.And it is quite likely worthwhile to consider whatlinkages to the CommitFest schema/code/interfaces are relevant. I'll also poke at SD (https://github.com/bestpractical/sd) as having some ideas worth looking at, as it combines: - Being inherently distributed, where bugs are assigned UUIDs as identifiers, and where data is pulled via Git repos - Essentially text-based, by default, so that it doesn't assume/mandate communicating with a web server - Somewhat agnostic of data sources; it can push/pull data to/from RT, Hiveminder, Trac, GitHub, Google Code, and Redmine. And there's a useful principle here: if the PostgreSQL project's issue tracker can sync data against something like SD, then developers have extra options. I rather wish that Slony was using one of those 6 trackers, rather than Bugzilla, as I could use SD+adaptor, and be able to work on issues offline. At any rate, a useful step would be to dust off the contents of that wiki page, and see if there are more details that are widely agreeable. The (sometimes modest) successes of the CommitFest application should provide some useful guidance. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
From: "Peter Eisentraut" <peter_e@gmx.net> > On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote: >> Also, I think it's about time we got ourselves some kind of bug >> tracker. I have no idea how to make that work without breaking >> workflow that works now, but a quick survey of my pgsql-bugs email >> suggests that this is far from the only thing slipping through the >> cracks. > > The problem is finding a usable bug tracking software. I think JIRA is very good. Almost all projects in Apache Software Foundation (ASF) including Tomcat, Hadoop, Apache HTTP server, use JIRA. With JIRA, we can know various counts such as the number of bugs per major/minor release, not-fixed bugs, new features in each major release, etc. Regards MauMau
On 05/28/2011 05:47 AM, MauMau wrote: > From: "Peter Eisentraut" <peter_e@gmx.net> >> On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote: >>> Also, I think it's about time we got ourselves some kind of bug >>> tracker. I have no idea how to make that work without breaking >>> workflow that works now, but a quick survey of my pgsql-bugs email >>> suggests that this is far from the only thing slipping through the >>> cracks. >> >> The problem is finding a usable bug tracking software. > > I think JIRA is very good. Almost all projects in Apache Software > Foundation (ASF) including Tomcat, Hadoop, Apache HTTP server, use JIRA. > With JIRA, we can know various counts such as the number of bugs per > major/minor release, not-fixed bugs, new features in each major release, well that is rather basic functionality of a tracker software and i would expect those to be a given, but I don't think that is where the problems are with implementing a tracker for postgresql.org... Stefan
On 05/27/2011 07:55 PM, Robert Haas wrote: > On Fri, May 27, 2011 at 12:21 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> "Joshua D. Drake"<jd@commandprompt.com> writes: >>> You have done what you need to do to check the status. Someone who knows >>> something about the bug should speak up at some point. >> >> That patch is waiting for a committer who knows something about Windows >> to pick it up. > > It might be useful, in this situation, for the OP to add this patch to > the CommitFest application. > > https://commitfest.postgresql.org/action/commitfest_view/open > > Also, I think it's about time we got ourselves some kind of bug > tracker. I have no idea how to make that work without breaking > workflow that works now, but a quick survey of my pgsql-bugs email > suggests that this is far from the only thing slipping through the > cracks. well as for just keeping track of -bugs I guess a very simple schema would go pretty far: * have some tool monitor the list and if it sees a new bug# make it a ticket/bugreport * if that bug number is mentioned in a commit close it * provide a dashboard of: a) bugs that never got a response b) bugs that got a response but never have been mentioned ina commit c) bugs that got mentioned in a commit but no stable release was done yet * provide a trivial interface (either mail or simple web interface - maybe in CF style) to make issues as "not a bug" or "not postgresql-core product" (which seems to be the top two non-big related inquiries we get on -bugs) this is more or less exactly what I hacked up back in early 2008 based on bugzilla (without actually exposing the BZ User-Interface at all - just using it as a tracker core and talking to it using the API it provides). Independent of whether we want to do a full tracker or not anywhere in the future we could at least start by prototyping with better automatic monitoring of -bugs. Stefan
On Sat, May 28, 2011 at 10:02 AM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > well as for just keeping track of -bugs I guess a very simple schema would > go pretty far: > > * have some tool monitor the list and if it sees a new bug# make it a > ticket/bugreport The bug numbers come from a database backed web form anyway - seems it would be a lot easier to just have that script write a record to a table. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 05/28/2011 12:19 PM, Dave Page wrote: > On Sat, May 28, 2011 at 10:02 AM, Stefan Kaltenbrunner > <stefan@kaltenbrunner.cc> wrote: >> well as for just keeping track of -bugs I guess a very simple schema would >> go pretty far: >> >> * have some tool monitor the list and if it sees a new bug# make it a >> ticket/bugreport > > The bug numbers come from a database backed web form anyway - seems it > would be a lot easier to just have that script write a record to a > table. maybe - but for a poc it was much easier to have something that had no dependency on any modification of the webinfrastructure(all it needed was an email subscription to the list), you also get some stuff like rss feeds, XML/CSV aggregation output, a commit log parser (and a GUI for playing even if you don't use it for anything officially) for free if you use some existing framework ;) For a real implemenation based on an existing tool you would probably modify the bug reporting form to post the bug report to the tracker and have that one send the report on behalf and with the sender address of the original reporter, that way the -pgsql-bugs list could exactly stay as it is now and if you wished to be able to use it as a not-only bugreport-form triggered tracker you could do that as well. Stefan
On Fri, May 27, 2011 at 5:54 PM, Andres Freund <andres@anarazel.de> wrote:
> If I see a bug in a region I know something about and its on a platform I care
> about (i.e. likely only linux) I try to do this. But its hard, in most
> situations one of you already did it. Tom and you are just to goddamn fast in
> many, many cases. Which is totally great, don't get me wrong, but makes it
> hard to beat you as a mere mortal ;)
It's funny to be lumped in with Tom, who leaves me in the dust!
But the problem is really with the bugs that never get a response, not
the ones that do. There are no shortage of things that neither Tom
nor I nor anyone else is working on.
> Do you like separate patches for the back branches or is that basically
> useless work?
If it doesn't apply cleanly, yes. It's also quite helpful to identify
how far the back-patch can reasonably go, and why.
> Related to doing stuff like that is that I really find it hard to write a patch
> that happens to be liked by Tom or you so it does not have to be mostly
> rewritten. For that to change for one I would like to have the Coding Style to
> be expanded because I think there are loads of rules that exist only in bits
> and bits on the mailing lists. For another I would like to get a patch back
> instead of rewritten because without knowing the individual reasons for the
> changes its sometimes rather hard to know what the reason for a specific change
> was. I do realize thats quite a bit of work for you which is why I hesitated
> writing that...
Well, frankly, I think you're doing pretty well. I find it's quite
helpful to have a patch to start with, even if I don't agree with the
approach, because it gives me an idea of what portions of the code
need to be changed and often makes it easier to understand what is
broken. But in your particular case, your recent patches have gone in
with minimal changes. I tend to avoid spelling out all the details
on-list because I don't want to be seen as nit-picking. If something
is a logic error or one or more places that needed to be changed were
altogether ignored, then I usually mention that, because those are,
well, important. But if I reindented the code to make pg_indent
mangle it less or corrected a typo in a comment or simplified
something like:
if (something)
{ do stuff;
}
else break;
more things;
to:
if (!something) break;
do stuff;
more things;
...then I don't tend to mention that, first because it's sort of
self-evident that the second one is clearer, second because I don't
want to demoralize people who have done basically good work by
pointing out trivial flaws, and third because it's a bit
time-consuming. But that really is third. If you want to know why I
did something, feel free to ask.
I have been really pleased to see that there is a growing group of
people who I can rely on to submit good stuff most of the time, stuff
that I can apply without spending a lot of time on it. If I were less
busy, I might spend more time hacking on patches that were marginal,
as I know Tom still does sometimes. But I just don't have the cycles
for it. It's far faster for me to read the patch and list the issues
than it is to fix them, unless the issues are trivial cosmetic stuff.
If there were fewer patches, I might spend more time hacking on
marginal patches, but as it is I mostly do that when I think that the
patch won't go in any other way. Actually, I think it's kind of good
that the volume is such as to preclude my doing that very often. It's
not so good for the patches that get bounced for lack of attention,
but I think overall the average quality of patches is improving
(perhaps partly for that reason?), and I expect that some of the
better and more prolific submitters will eventually get commit bits of
their own. I can only hope that some of those people will be
interested in helping with the CF work. It is easy to find people who
are willing to commit their own patches. Finding people who are
willing to commit other people's patches is the tough part.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > well that is rather basic functionality of a tracker software and i > would expect those to be a given, but I don't think that is where the > problems are with implementing a tracker for postgresql.org... Right, the problem has been the lukewarm response from the hackers who would be using it every day, and without whose buy-in using a bug tracker would be possible, but much more difficult. Bug tracking software is definitely religious war territory; most people have a bug tracker they use and tolerate, and pretty much everyone has a bug tracker that they absolutely despise (hi JIRA!). Therefore, I suggest we adopt the first one that someone takes the time to build and implement, along with a plan for keeping it up to date. My own bare bones wish list for such a tracker is: * Runs on Postgres * Has an email interface Make no mistake, whichever we choose, the care of feeding of such a beast will require some precious resources in time from at least two people, probably more. If there is anyone in the community that wants to help the project but hasn't found a way, this is your chance to step up! :) - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201105282322 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk3hvCgACgkQvJuQZxSWSsi8gwCfQq/2WRhtnN8HJKoup5KxTrI6 S6QAn1rhm5QIr5cLplhz6U67ZSv6njK8 =oU4a -----END PGP SIGNATURE-----
On Sat, May 28, 2011 at 11:23 PM, Greg Sabino Mullane <greg@turnstep.com> wrote: > My own bare bones wish list for such a tracker is: > > * Runs on Postgres > * Has an email interface > > Make no mistake, whichever we choose, the care of feeding of such a > beast will require some precious resources in time from at least two > people, probably more. If there is anyone in the community that > wants to help the project but hasn't found a way, this is your chance > to step up! :) Yeah, agreed. My basic requirements are: 1. Given a bug number, find the pgsql-bugs emails that mention it in the subject line. Note that the archives would actually MOSTLY do this ,but for the stupid month-boundary problem which we seem unable to fix despite having some of the finest engineers in the world. 2. Associate some kind of status like "OPEN", "FIXED", "NOTABUG", "WONTFIX", etc. with each such bug via web interface. I'm not asking for a lot. In fact, less may be more. We don't want to have to do a lot of work to keep something up to date. But for the love of pity, there should be some way to get a list of which bugs we haven't fixed yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, May 28, 2011 at 11:23 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:
>> My own bare bones wish list for such a tracker is:
>>
>> * Runs on Postgres
>> * Has an email interface
>>
>> Make no mistake, whichever we choose, the care of feeding of such a
>> beast will require some precious resources in time from at least two
>> people, probably more. If there is anyone in the community that
>> wants to help the project but hasn't found a way, this is your chance
>> to step up! :)
> Yeah, agreed. My basic requirements are:
> 1. Given a bug number, find the pgsql-bugs emails that mention it in
> the subject line. Note that the archives would actually MOSTLY do
> this ,but for the stupid month-boundary problem which we seem unable
> to fix despite having some of the finest engineers in the world.
Many, many, many bug issues are not associated with a bug report
submitted through the web interface. People mail stuff to pgsql-bugs
manually, or issues turn up in threads on other lists. If a tracker
can only find things submitted through the web interface, that is not
going to lead to everyone filing bugs that way; it's going to lead to
the tracker being ignored as useless.
> 2. Associate some kind of status like "OPEN", "FIXED", "NOTABUG",
> "WONTFIX", etc. with each such bug via web interface.
Anything that even pretends to be a bug tracker will do that. The
real question is, who is going to keep it up to date? GSM has the
right point of view here: we need at least a couple of people who
are willing to invest substantial amounts of time, or it's not going
to go anywhere. Seeing that we can barely manage to keep the mailing
list moderator positions staffed, I'm not hopeful.
regards, tom lane
On Sun, May 29, 2011 at 12:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 1. Given a bug number, find the pgsql-bugs emails that mention it in >> the subject line. Note that the archives would actually MOSTLY do >> this ,but for the stupid month-boundary problem which we seem unable >> to fix despite having some of the finest engineers in the world. > > Many, many, many bug issues are not associated with a bug report > submitted through the web interface. People mail stuff to pgsql-bugs > manually, or issues turn up in threads on other lists. If a tracker > can only find things submitted through the web interface, that is not > going to lead to everyone filing bugs that way; it's going to lead to > the tracker being ignored as useless. > >> 2. Associate some kind of status like "OPEN", "FIXED", "NOTABUG", >> "WONTFIX", etc. with each such bug via web interface. > > Anything that even pretends to be a bug tracker will do that. The > real question is, who is going to keep it up to date? GSM has the > right point of view here: we need at least a couple of people who > are willing to invest substantial amounts of time, or it's not going > to go anywhere. Seeing that we can barely manage to keep the mailing > list moderator positions staffed, I'm not hopeful. The issues that you raise are real ones, but doing nothing isn't better. Right now we have no organized tracking of ANY bugs, and if someone were hypothetically willing to help with that they would have nowhere to start. This is a big enough problem that we should at least TRY to get our arms around it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 29 May 2011 14:04, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Anything that even pretends to be a bug tracker will do that. The > real question is, who is going to keep it up to date? GSM has the > right point of view here: we need at least a couple of people who > are willing to invest substantial amounts of time, or it's not going > to go anywhere. Seeing that we can barely manage to keep the mailing > list moderator positions staffed, I'm not hopeful. > Well the good news is that first-pass triage of bug reports can be done by pretty much anybody who is a moderately experienced postgres user; they don't even need to be a hacker. They just need to know when to send back a RTFM link, when to say "you didn't tell us your PG version" / "post your query" / "post your explain analyse" / "post your show all", and when to kick the bug report up to a sage hacker. It's not glamorous work, but it is a very accessible way to contribute, without the need to block out hours at a time. A bug wrangler could very readily log in, sort out reports for 20 minutes and then go do something else with the rest of their day. Cheers, BJ
Brendan Jurd <direvus@gmail.com> writes:
> On 29 May 2011 14:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Anything that even pretends to be a bug tracker will do that. The
>> real question is, who is going to keep it up to date? GSM has the
>> right point of view here: we need at least a couple of people who
>> are willing to invest substantial amounts of time, or it's not going
>> to go anywhere. Seeing that we can barely manage to keep the mailing
>> list moderator positions staffed, I'm not hopeful.
> It's not glamorous work, but it is a very accessible way to
> contribute, without the need to block out hours at a time. A bug
> wrangler could very readily log in, sort out reports for 20 minutes
> and then go do something else with the rest of their day.
Yup, you're right. But the same comments can be made about mailing list
moderation, and I've lost count of the number of fails we've seen in
that domain. Anyway, as I said earlier, I'm not standing in the way of
anybody who wants to volunteer.
regards, tom lane
On 05/29/2011 06:04 AM, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Sat, May 28, 2011 at 11:23 PM, Greg Sabino Mullane <greg@turnstep.com> wrote: >>> My own bare bones wish list for such a tracker is: >>> >>> * Runs on Postgres >>> * Has an email interface >>> >>> Make no mistake, whichever we choose, the care of feeding of such a >>> beast will require some precious resources in time from at least two >>> people, probably more. If there is anyone in the community that >>> wants to help the project but hasn't found a way, this is your chance >>> to step up! :) > >> Yeah, agreed. My basic requirements are: > >> 1. Given a bug number, find the pgsql-bugs emails that mention it in >> the subject line. Note that the archives would actually MOSTLY do >> this ,but for the stupid month-boundary problem which we seem unable >> to fix despite having some of the finest engineers in the world. > > Many, many, many bug issues are not associated with a bug report > submitted through the web interface. People mail stuff to pgsql-bugs > manually, or issues turn up in threads on other lists. If a tracker > can only find things submitted through the web interface, that is not > going to lead to everyone filing bugs that way; it's going to lead to > the tracker being ignored as useless. yeah that's why the original proposal had the plan to provide an email interface that you could CC or forward a mail to that would turn into a bug report, that would still require someone to actually do that, but it is probably not different from moving a discussion on -general that turns out to be a bug to -hackers (or -bugs). > >> 2. Associate some kind of status like "OPEN", "FIXED", "NOTABUG", >> "WONTFIX", etc. with each such bug via web interface. > > Anything that even pretends to be a bug tracker will do that. The > real question is, who is going to keep it up to date? GSM has the > right point of view here: we need at least a couple of people who > are willing to invest substantial amounts of time, or it's not going > to go anywhere. Seeing that we can barely manage to keep the mailing > list moderator positions staffed, I'm not hopeful. I think that a tracker would require a different kind of volunteer that is much easier to find than ML-moderation, but I guess unless we actually try we will never know. Stefan
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@gmx.net> writes:
> That doesn't mean that better integration cannot be worked on later, but
> this illusion that a bug tracker must have magical total awareness of
> the entire flow of information in the project from day one is an
> illusion and has blocked this business for too long IMO.
If it has only a partial view of the set of bugs being worked on, it's
not going to meet the goals that are being claimed for it.
I don't doubt that somebody could run around and link every discussion
about a bug into the tracker. I'm just dubious that that actually
*will* happen with enough reliability to make the tracker more useful
than a mailing-list search.
In the end, I think that requests for a tracker mostly come from people
who are not part of this community, or at least not part of its mailing
lists (which is about the same thing IMO). If they submitted a bug
report via the lists, they're generally going to get replies via email,
and that seems sufficient to me. But if they submitted a report via the
web form, they might well be expecting that they can track what's going
on with it on a web page. And that's not unreasonable. But we could
fix that without any changes at all in our work processes. Just have
the webform add a "cc: bugbot-bugNNNN@postgresql.org" to each submitted
email, and set up a bot to collect the traffic and display it on a
suitable web page. (Spam filtering left as an exercise for the reader.)
regards, tom lane
Hi Tom, On 05/29/2011 11:05 AM, Tom Lane wrote: > In the end, I think that requests for a tracker mostly come from people > who are not part of this community, or at least not part of its mailing > lists (which is about the same thing IMO). I think that's a bit harsh. I assume you consider GSM a part of the community and he's asking for a tracker, even going to the trouble of posting a "Help Wanted!" article about it. > If they submitted a bug > report via the lists, they're generally going to get replies via email, > and that seems sufficient to me. But if they submitted a report via the > web form, they might well be expecting that they can track what's going > on with it on a web page. And that's not unreasonable. But we could > fix that without any changes at all in our work processes. Just have > the webform add a "cc: bugbot-bugNNNN@postgresql.org" to each submitted > email, and set up a bot to collect the traffic and display it on a > suitable web page. (Spam filtering left as an exercise for the reader.) I think there's more to a tracker than having bug submitters find all the emails related to it. For example, one can use it to aggregate interesting data, like how many bugs reported per person/email address, or PostgreSQL version or OS (or may be I'm not aware and something like this is already going on behind the submission form). Anyway, I may be willing to do some work on a tracker--if there's interest-- since at least part of the work could fit in with the database interface area of the Pyrseas project. To collect info/discuss, I could use http://wiki.postgresql.org/wiki/TrackerDiscussion but I see there's a request to not modify/add anything without talking to Stefan Kaltenbrunner. Would a new page be preferable? All the best, Joe
On 05/29/2011 05:47 PM, Joe Abbate wrote: > Hi Tom, > > On 05/29/2011 11:05 AM, Tom Lane wrote: >> In the end, I think that requests for a tracker mostly come from people >> who are not part of this community, or at least not part of its mailing >> lists (which is about the same thing IMO). > > I think that's a bit harsh. I assume you consider GSM a part of the > community and he's asking for a tracker, even going to the trouble of > posting a "Help Wanted!" article about it. > >> If they submitted a bug >> report via the lists, they're generally going to get replies via email, >> and that seems sufficient to me. But if they submitted a report via the >> web form, they might well be expecting that they can track what's going >> on with it on a web page. And that's not unreasonable. But we could >> fix that without any changes at all in our work processes. Just have >> the webform add a "cc: bugbot-bugNNNN@postgresql.org" to each submitted >> email, and set up a bot to collect the traffic and display it on a >> suitable web page. (Spam filtering left as an exercise for the reader.) [...] > To collect info/discuss, I could use > http://wiki.postgresql.org/wiki/TrackerDiscussion but I see there's a > request to not modify/add anything without talking to Stefan > Kaltenbrunner. Would a new page be preferable? feel free to reuse/edit the page as you like it(I have just removed the notice) - the "don't edit" thingy was added because people started to find the page via google (while searching for a tracker/bugreporting tool) and considered it official status information or a way to sell^pitch their preferred tool to me personally. Stefan
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@freedomcircle.com> wrote: > Anyone interested in the tracker, please visit > http://wiki.postgresql.org/wiki/TrackerDiscussion and add your > feedback/input. I think this illustrates exactly what we *don't* want to happen with a bug tracker. We want the discussion to stay *here* not on some other medium accessible only through the web and editable only through a web interface.... Also your summary seems to have missed the point on the "has email interface" requirement. The table of features you listed has just "Creation of bugs via mail interface" as the only feature that is accessible from email. I'm not sure what Robert meant but I suspect he meant what I would want which is the ability to add comments, close bugs, set other properties, etc. By email. My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to that email. My ideal bug tracker is the debian one which basically stays out of your way and lets you cc any message to a specific bug at nnnn@bugs.debian.org which archives that message in the bug and sends it to anyone listening to the bug. And you can have control commands to close it or edit it -- basically making all our existing "that's not a bug bleah bleah" messages into "close nnn; that's not a bug bleah bleah" messages. -- greg
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 05/30/2011 04:26 AM, Greg Stark wrote: > On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma@freedomcircle.com> wrote: >> Anyone interested in the tracker, please visit >> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your >> feedback/input. > > I think this illustrates exactly what we *don't* want to happen with a > bug tracker. We want the discussion to stay *here* not on some other > medium accessible only through the web and editable only through a web > interface.... > > Also your summary seems to have missed the point on the "has email > interface" requirement. The table of features you listed has just > "Creation of bugs via mail interface" as the only feature that is > accessible from email. > > I'm not sure what Robert meant but I suspect he meant what I would > want which is the ability to add comments, close bugs, set other > properties, etc. By email. My biggest gripe about bugzilla was that it > sent you an email with updates to the bug but you couldn't respond to > that email. well bugzilla has an inbound email interface as well that can both be used to creande and to manipulate bugs (as in "mails that have the bug-id in the subject will be added as a comment"). The demo installation did that by simply being subscribed to -bugs. > > My ideal bug tracker is the debian one which basically stays out of > your way and lets you cc any message to a specific bug at > nnnn@bugs.debian.org which archives that message in the bug and sends > it to anyone listening to the bug. And you can have control commands > to close it or edit it -- basically making all our existing "that's > not a bug bleah bleah" messages into "close nnn; that's not a bug > bleah bleah" messages. that is what every emailinterface should be able to provide ;). However the real issue with say BZ(or most other trackers) in this role is that in order to attribute a bug report or a comment to the original author/person you have to trust the "From" in the email and basically autocreate an account based on that information for the tracker to work with. Stefan
Excerpts from Greg Stark's message of dom may 29 22:26:21 -0400 2011: > My ideal bug tracker is the debian one which basically stays out of > your way and lets you cc any message to a specific bug at > nnnn@bugs.debian.org which archives that message in the bug and sends > it to anyone listening to the bug. And you can have control commands > to close it or edit it -- basically making all our existing "that's > not a bug bleah bleah" messages into "close nnn; that's not a bug > bleah bleah" messages. Yeah. The other good thing about the Debian thing is that email is first-class citizen; each "bug history" is basically an mbox. All the other systems I've looked at try to do the silly thing of extracting the text from the email and inserting into a "comment" of some sort, which is ocassionally problematic because of random annoyances in email messages; and when you want to get down to investigating exactly what was discussed in the email thread, the interesting bits aren't there. In the Debian system, you can get the mbox and open it with your favorite email reading tool instead. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 05/29/2011 05:17 AM, Peter Eisentraut wrote: > Here is a list to choose from: > http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems > I turned this into a spreadsheet to sort and prune more easily; if anyone wants that let me know, it's not terribly useful beyond what I'm posting here. 44 total, 16 that are open-source. I would say that having an e-mail interface is the next major cut to make. While distasteful, it's possible for this project to adopt a solution that doesn't use PostgreSQL, and one interesting candidate is in that category. It's not feasible to adopt one that doesn't integrate well with e-mail though. List of software without listed e-mail integration: Fossil, GNATS, Liberum Help Desk, MantisBT, org-mode, Flyspray, ikiwiki, Trac. The 8 F/OSS programs left after that filter are: OTRS Debbugs Request Tracker Zentrack LibreSource Redmine Roundup Bugzilla The next two filters you might apply are: Support for Git: Redmine, Bugzilla PostgreSQL back-end: OTRS, Request Tracker, LibreSource, Redmine, Roundup, Bugzilla There are a couple of additional nice to have items I saw on the feature list, and they all seem to spit out just Redmine & Bugzilla. Those are the two I've ended up using the most on PostgreSQL related projects, too, so that isn't a surprise to me. While I'm not a strong fan of Redmine, it has repeatedly been the lesser of the evils available here for three different companies I've worked at or dealt with. Greg Stark is right that Debbugs has a lot of interesting features similar to the desired workflow here. It's not tied to just Debian anymore; the GNU project is also using it now. And the database backend isn't that terrible to consider: it's flat files with a BerkleyDB index built on top. I think if it was perfect except for that, it would still be worth considering. Debbugs is far from a general purpose solution though, so any customization to support differences in this project's workflow would likely end up being one-off hacks. The VCS support might be a problem, but I've gotten the impression that git is increasingly popular for other Debian work. Since the program is in Perl, I can't imagine it's a gigantic task to switch that out, and probably one other people would like to see. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
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 Mon, May 30, 2011 at 04:26, Greg Stark <gsstark@mit.edu> wrote: > On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma@freedomcircle.com> wrote: >> Anyone interested in the tracker, please visit >> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your >> feedback/input. > > I think this illustrates exactly what we *don't* want to happen with a > bug tracker. We want the discussion to stay *here* not on some other > medium accessible only through the web and editable only through a web > interface.... +<as high number as my quota currently goes> It's fine that a bug tracker *tracks* bugs. It should not control them. That's not how this community currently works, and a lot of people have said that's how they want it to stay (at least for now). > Also your summary seems to have missed the point on the "has email > interface" requirement. The table of features you listed has just > "Creation of bugs via mail interface" as the only feature that is > accessible from email. > > I'm not sure what Robert meant but I suspect he meant what I would > want which is the ability to add comments, close bugs, set other > properties, etc. By email. My biggest gripe about bugzilla was that it > sent you an email with updates to the bug but you couldn't respond to > that email. I agree with these too :-) It's also missing what I believe is a very important requirement - it needs to have an extensive, and fully supported, API. So that we can easily make it work together with our other services. > My ideal bug tracker is the debian one which basically stays out of > your way and lets you cc any message to a specific bug at > nnnn@bugs.debian.org which archives that message in the bug and sends > it to anyone listening to the bug. And you can have control commands > to close it or edit it -- basically making all our existing "that's > not a bug bleah bleah" messages into "close nnn; that's not a bug > bleah bleah" messages. No direct experience with the debian tracker, but I agree that being able to do all those things from mail is very important. If it *also* provides a way to do this from the web, that's even better. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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 05/27/2011 08:36 AM, MauMau wrote: > I posted a patch for bug #6011 to pgsql-hackers several days ago. How > can I check the status of bug fixes? I'm worried that the patch might > be forgotten, because bug #5842 was missed for two months until Bruce > noticed it. Discussion here seems to have wandered far away from useful suggestions for you, let's see if that's possible to return to that. Best way to confirm when a bug is resolved is to subscribe to the pgsql-committers mailing list. If a commit for this fix appears, odds are good the original bug number will be referenced. Even if it isn't, you may recognize it via its description. Until you see that, the bug is almost certainly still open. Bugs that are considered to impact the current version under development are sometimes listed at http://wiki.postgresql.org/wiki/Open_Items Adding a bug to there that's not really specific to the new version may not be considered good form by some. It is the closest thing to an open bug tracker around though, and adding items to there means they won't be forgotten about; it's checked regularly by developers considering when it's a good time to release another alpha or beta. In my mind, clarifying what circumstances it's appropriate for people to put a bug onto the Open Items list would be a useful way to spend a little time. Certainly more productive than trying firing more bullets at the unkillable zombie that is bug tracking software. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
On Mon, May 30, 2011 at 16:52, Joe Abbate <jma@freedomcircle.com> wrote: > Hi Magnus, > > On 05/30/2011 08:45 AM, Magnus Hagander wrote: >> It's fine that a bug tracker *tracks* bugs. It should not control >> them. That's not how this community currently works, and a lot of >> people have said that's how they want it to stay (at least for now). > > If I may belabor the point, what do you see as an example of > "controlling" the bugs? To put some context, there could be at least > three ways a bug could be closed when someone commits a patch that fixes > (or claims to fix) a bug: > > a. The committer has to use a web interface to indicate the bug is closed > b. The committer has to send an email to a mail interface > c. The commit message gets routed to a mail interface that, seeing > something like "bug #1234" in the first line, automatically closes the bug > > Based on the discussion so far, it's obvious that option b is more > desired than a (where the tracker is, in a sense, controlling *you*), > but is option c --while presumably more desirable since there's one less > thing to do or remember-- an instance of "control", since the tracker > takes an automatic action? Or do you want the tracker *not* to require > or take any of the actions, i.e., let someone/thing other than the > committer/commit message worry about tracking the bug's status, leaving > it up to volunteers, as Tom said? I believe b is perfectly fine in this, and to me the preferred way. We always respond to the original message with something like "yeah, patched <over here>" or something like that anyway, so I don't (personally) see a need for the actual commit message to be able to do it. The case I want to avoid is (a). And if it's possible to make (b) just be the -hackers mailinglist and putting a keyword in the right place, that minimizes the impact on those who spend a lot of time with it (far more than me..), which is always good. I personally don't think it's good to expect "external volunteers" (external when compared to committers) to maintain *all* the bug statuses. What I want/need those to do is to take care of everything that the system did *not* pick up properly, or any case when the hacker/committer forgot something, or things like that. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Mon, May 30, 2011 at 2:26 AM, Greg Stark <gsstark@mit.edu> wrote: > On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma@freedomcircle.com> wrote: >> Anyone interested in the tracker, please visit >> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your >> feedback/input. > > I think this illustrates exactly what we *don't* want to happen with a > bug tracker. We want the discussion to stay *here* not on some other > medium accessible only through the web and editable only through a web > interface.... That's more or less why I was suggesting SD as a possible model, as a bug tracker that begins with a command line interface consciously analogous to version management software. (See attachment for samples of the help...) > Also your summary seems to have missed the point on the "has email > interface" requirement. The table of features you listed has just > "Creation of bugs via mail interface" as the only feature that is > accessible from email. I recall RT (on one of the lists) having a somewhat sophisticated email-based interface, however, I'm not at all sure that this would be considered a good thing, as it would be pretty "in your face" that you are submitting specially-constructed email messages to control things. > I'm not sure what Robert meant but I suspect he meant what I would > want which is the ability to add comments, close bugs, set other > properties, etc. By email. My biggest gripe about bugzilla was that it > sent you an email with updates to the bug but you couldn't respond to > that email. Having used a number of versions of Bugzilla over the years, I'm somewhat comfortable with its foibles, but that's not nearly the same thing as actually liking it. > My ideal bug tracker is the debian one which basically stays out of > your way and lets you cc any message to a specific bug at > nnnn@bugs.debian.org which archives that message in the bug and sends > it to anyone listening to the bug. And you can have control commands > to close it or edit it -- basically making all our existing "that's > not a bug bleah bleah" messages into "close nnn; that's not a bug > bleah bleah" messages. http://www.chiark.greenend.org.uk/~ian/debbugs/ I suppose it would be interesting to inject a little more code into this that would collect other interesting bits of data, such as the commit hash of a patch that is believed to fix the bug, and version numbers believed to include fixes for the bug. Also interesting would be a reference to commitfest work relating to the bug. Perhaps it's enough to just send an email "to the bug" indicating appropriate URLs, as opposed to requiring any first-class extensions to support this sort of data. I think we'd probably want a web interface that can point not merely to messages, but also to the whole threads of discussion. That way, reporting that an email thread relates to bug 72521 requires only that *ONE* of the messages in the thread includes "cc: 72521@bugs.postgresql.org" (or similar). -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
Attachment
On Sun, May 29, 2011 at 10:09 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > well bugzilla has an inbound email interface as well that can both be > used to creande and to manipulate bugs (as in "mails that have the > bug-id in the subject will be added as a comment"). Ugh, putting it in the subject plays poorly with MUAs like gmail that don't understand threading and group messages by subject. -- greg
Hi Greg, On 05/29/2011 10:26 PM, Greg Stark wrote: > On Sun, May 29, 2011 at 3:36 PM, Joe Abbate <jma@freedomcircle.com> wrote: >> Anyone interested in the tracker, please visit >> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your >> feedback/input. > > I think this illustrates exactly what we *don't* want to happen with a > bug tracker. We want the discussion to stay *here* not on some other > medium accessible only through the web and editable only through a web > interface.... I have no problem keeping the discussion here, but I thought perhaps not everyone on -hackers wanted to see the discussion (there was a -tracker list that became defunct, according to the page--don't know if people want to resurrect it). > Also your summary seems to have missed the point on the "has email > interface" requirement. The table of features you listed has just > "Creation of bugs via mail interface" as the only feature that is > accessible from email. My summary is in the section titled "Discussion Points" (and it was not meant to be all-inclusive). The second section, titled "Previous Content" was there before and I didn't want to eliminate it entirely. You're referring to the second section. > I'm not sure what Robert meant but I suspect he meant what I would > want which is the ability to add comments, close bugs, set other > properties, etc. By email. My biggest gripe about bugzilla was that it > sent you an email with updates to the bug but you couldn't respond to > that email. > > My ideal bug tracker is the debian one which basically stays out of > your way and lets you cc any message to a specific bug at > nnnn@bugs.debian.org which archives that message in the bug and sends > it to anyone listening to the bug. And you can have control commands > to close it or edit it -- basically making all our existing "that's > not a bug bleah bleah" messages into "close nnn; that's not a bug > bleah bleah" messages. I see that a full interface is very desirable to you (and others). That confirms the order of my summary list of requirements (mail interface is listed before web interface). I'll admit that I became interest in assisting with this effort due to the latter rather than the former, but I don't mind carrying the ball forward, for now. All the best, Joe
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
<p><br /> On 2011-05-30 4:31 PM, "Peter Eisentraut" <<a href="mailto:peter_e@gmx.net" target="_blank">peter_e@gmx.net</a>>wrote:<br /> ><br /> > On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote:<br/> > > I've summarizes the main points made in the recent discussion and did<br /> > > some minor additionalresearch on the lists suggested by Peter and<br /> > > Chris Browne. Anyone interested in the tracker, pleasevisit<br /> > > <a href="http://wiki.postgresql.org/wiki/TrackerDiscussion" target="_blank">http://wiki.postgresql.org/wiki/TrackerDiscussion</a>and add your<br /> > > feedback/input.<br /> ><br/> > Based on that, and past discussions, and things we've tried in the past,<br /> > and gut feeling, and soon, it looks like Request Tracker would appear<br /> > to be the next best thing to consider trying out. What do peoplethink<br /> > about that?<p>My suspicion is that RT may be rather a lot heavier weight in terms of how it wouldhave to affect process than people would be happy with.<br /><p>What has been pretty clearly expressed is that variousof the developers prefer for the mailing lists and archives thereof to be the primary data source and the "venue"for bug discussions.<p>RT, and Bugzilla, and pretty well the bulk of the issue trackers out there are designed tothemselves be the "venue" for discussions, and that's not consistent with the preference for email discussions.<p>Thereare Debian packages for RT 3.8, and I imagine it may be worth tossing an instance, but I'd definitelycommend trying to minimize the amount of deployment effort done, as I think there's a fair chance that a numberof devs (I'll pick on Greg Stark :-)) are liable to rebel against it. It'd be interesting to see the reactions tothe interaction between RT, -hackers, and -bugs for a bug or three...<p>I'd be more optimistic that debbugs, or an adaptionthereof, might more nearly fit into the workflow.
On Mon, May 30, 2011 at 8:16 PM, Christopher Browne <cbbrowne@gmail.com> wrote: > On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote: >> On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote: >> > I've summarizes the main points made in the recent discussion and did >> > some minor additional research on the lists suggested by Peter and >> > Chris Browne. Anyone interested in the tracker, please visit >> > http://wiki.postgresql.org/wiki/TrackerDiscussion and add your >> > feedback/input. >> >> Based on that, and past discussions, and things we've tried in the past, >> and gut feeling, and so on, it looks like Request Tracker would appear >> to be the next best thing to consider trying out. What do people think >> about that? > > My suspicion is that RT may be rather a lot heavier weight in terms of how > it would have to affect process than people would be happy with. > > What has been pretty clearly expressed is that various of the developers > prefer for the mailing lists and archives thereof to be the primary data > source and the "venue" for bug discussions. > > RT, and Bugzilla, and pretty well the bulk of the issue trackers out there > are designed to themselves be the "venue" for discussions, and that's not > consistent with the preference for email discussions. > > There are Debian packages for RT 3.8, and I imagine it may be worth tossing > an instance, but I'd definitely commend trying to minimize the amount of > deployment effort done, as I think there's a fair chance that a number of > devs (I'll pick on Greg Stark :-)) are liable to rebel against it. It'd be > interesting to see the reactions to the interaction between RT, -hackers, > and -bugs for a bug or three... > > I'd be more optimistic that debbugs, or an adaption thereof, might more > nearly fit into the workflow. Yeah, that's my feeling, as well. I have used RT and I found that the web interface was both difficult to use and unwieldly for tickets containing large numbers of messages. Maybe those those things have been improved, but frankly if RT or Bugzilla is the best we can come up with then I'd rather not have a bug tracker at all. See also: Linus's opinion on CVS. I don't personally care if I need to go to a web interface to mark bugs closed. Being able to do it via email is possibly useful, but I don't really care about it personally. Sounds like we should have it for the benefit of those who do, but it's not my priority. What I do care about is that the tracker doesn't get in the way of *discussion* of bugs. IOW, if people just reply-to-all on bug reports as they do now, and either include some special tag in the subject line or copy some special address on the CC list, it should all get sucked into the appropriate bug report. The number of people reading and replying to emails on pgsql-bugs is already insufficient, perhaps because of the (incorrect) perception that Tom does or will fix everything and no one else needs to care. So anything that makes it harder for people to follow along and participate is a non-starter IMV. Based on the discussion thus far, it sounds like debbugs might be reasonably close to what we need. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 31 May 2011 11:52, Robert Haas <robertmhaas@gmail.com> wrote: > I have used RT and I found that the > web interface was both difficult to use and unwieldly for tickets > containing large numbers of messages. A big loud "ditto" from me on this point. Cheers, BJ
Christopher Browne <cbbrowne@gmail.com> writes:
> On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote:
>> Based on that, and past discussions, and things we've tried in the past,
>> and gut feeling, and so on, it looks like Request Tracker would appear
>> to be the next best thing to consider trying out. What do people think
>> about that?
> I'd be more optimistic that debbugs, or an adaption thereof, might more
> nearly fit into the workflow.
Yeah, that's my impression as well.
regards, tom lane
On Mon, May 30, 2011 at 09:52:38PM -0400, Robert Haas wrote: > On Mon, May 30, 2011 at 8:16 PM, Christopher Browne <cbbrowne@gmail.com> wrote: > > On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote: > >> On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote: > >> > I've summarizes the main points made in the recent discussion and did > >> > some minor additional research on the lists suggested by Peter and > >> > Chris Browne. Anyone interested in the tracker, please visit > >> > http://wiki.postgresql.org/wiki/TrackerDiscussion and add your > >> > feedback/input. > >> > >> Based on that, and past discussions, and things we've tried in the past, > >> and gut feeling, and so on, it looks like Request Tracker would appear > >> to be the next best thing to consider trying out. What do people think > >> about that? > > > > My suspicion is that RT may be rather a lot heavier weight in terms of how > > it would have to affect process than people would be happy with. > > > > What has been pretty clearly expressed is that various of the developers > > prefer for the mailing lists and archives thereof to be the primary data > > source and the "venue" for bug discussions. > > > > RT, and Bugzilla, and pretty well the bulk of the issue trackers out there > > are designed to themselves be the "venue" for discussions, and that's not > > consistent with the preference for email discussions. > > > > There are Debian packages for RT 3.8, and I imagine it may be worth tossing > > an instance, but I'd definitely commend trying to minimize the amount of > > deployment effort done, as I think there's a fair chance that a number of > > devs (I'll pick on Greg Stark :-)) are liable to rebel against it. It'd be > > interesting to see the reactions to the interaction between RT, -hackers, > > and -bugs for a bug or three... > > > > I'd be more optimistic that debbugs, or an adaption thereof, might more > > nearly fit into the workflow. > > Yeah, that's my feeling, as well. I have used RT and I found that the > web interface was both difficult to use and unwieldly for tickets > containing large numbers of messages. Maybe those those things have > been improved, but frankly if RT or Bugzilla is the best we can come > up with then I'd rather not have a bug tracker at all. See also: > Linus's opinion on CVS. > > I don't personally care if I need to go to a web interface to mark > bugs closed. Being able to do it via email is possibly useful, but I > don't really care about it personally. Sounds like we should have it > for the benefit of those who do, but it's not my priority. What I do > care about is that the tracker doesn't get in the way of *discussion* > of bugs. IOW, if people just reply-to-all on bug reports as they do > now, and either include some special tag in the subject line or copy > some special address on the CC list, it should all get sucked into the > appropriate bug report. The number of people reading and replying to > emails on pgsql-bugs is already insufficient, perhaps because of the > (incorrect) perception that Tom does or will fix everything and no one > else needs to care. So anything that makes it harder for people to > follow along and participate is a non-starter IMV. > > Based on the discussion thus far, it sounds like debbugs might be > reasonably close to what we need. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > We use RT here and it is very customizable. In particular, it is easy to have the basic process be completely via Email, if desired. It seems that the general opinion is to use Email and consolidate the information in the bug tracking system. RT can definitely step into the background as needed. Regards, Ken
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 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 thatemail. 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 existingbug. You can also > very easily attach files to bugs this way. http://www.bugzilla.org/features/#email-in Regards, Kim
On Mon, May 30, 2011 at 6:52 PM, Robert Haas <robertmhaas@gmail.com> wrote: > The number of people reading and replying to > emails on pgsql-bugs is already insufficient, perhaps because of the > (incorrect) perception that Tom does or will fix everything and no one > else needs to care. So anything that makes it harder for people to > follow along and participate is a non-starter IMV. Actually I think most of our bugs don't come in from pgsql-bugs. I think we want to add other bugs that come up from discussions on -hackers or -general which for whatever reason don't get immediately fixed. The important thing about a bug tracker is that it has all the bugs (at least all the ones you intend to fix) so they don't get forgotten about. Keeping a single list takes the stress off individuals trying to remember what needs to get done. I'm actually not nearly so concerned as other people that it contain all the detailed discussion of the bug -- we can always search for the bug# on the list or follow links on the bug tracker. Fwiw it is pretty nice to be able to include a "Closes: #1001" in the commit and have that close the bug and associate the commit to the commit as soon as it's pushed. Anything to make keeping things clean and up to date as simple and low-overhead as possible. -- greg
Kim Bisgaard <kim+pg@alleroedderne.adsl.dk> writes:
> On 2011-05-30 04:26, Greg Stark wrote:
>> My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to
thatemail.
> 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
existingbug. 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@alleroedderne.adsl.dk> writes: >> On 2011-05-30 04:26, Greg Stark wrote: >>> My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to thatemail. > >> 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 existingbug. You can also >>> very easily attach files to bugs this way. > > The claim is there all right, but the feature seems spectacularly > undocumented otherwise. I wanted to see if it worked like debbugs > (ie, you just cc: some mail to the bug tracker), but there's no > information about exactly how to use it. Depends on what exactly you are looking for... * that feature relies on finding a valid bugid in the subject, if it finds one it will add the email ass a comment * if you would prefer something like nnnnnn-bug@tracker.postgresql.org for adding to existing bugs, that would be a trivial thing to add as a feature(have the MTA split the localpart and pass it as a parameter in the pipe-transport to the email_in.pl script) * the challenge is more about creating "new" bugs, because for that you need a bz account (or maybe a community account in our case) by default. We could certainly modify the feature so that it will autocreate bz accounts as soon as we see a new emailaddress sending email in but that will be fairly hard to control spamwise. Stefan
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@mit.edu> wrote: > On Sun, May 29, 2011 at 10:09 PM, Stefan Kaltenbrunner > <stefan@kaltenbrunner.cc> wrote: >> well bugzilla has an inbound email interface as well that can both be >> used to creande and to manipulate bugs (as in "mails that have the >> bug-id in the subject will be added as a comment"). > > Ugh, putting it in the subject plays poorly with MUAs like gmail that > don't understand threading and group messages by subject. +<a lot>. Changing the subject will break a lot of things - it's annoying enough already with people who do that (when they shouldn't - doing it when the thread actually changes, is obviously good) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, May 31, 2011 at 07:08, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > On 05/31/2011 05:42 AM, Tom Lane wrote: >> Kim Bisgaard <kim+pg@alleroedderne.adsl.dk> writes: >>> On 2011-05-30 04:26, Greg Stark wrote: >>>> My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to thatemail. >> >>> 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 existingbug. You can also >>>> very easily attach files to bugs this way. >> >> The claim is there all right, but the feature seems spectacularly >> undocumented otherwise. I wanted to see if it worked like debbugs >> (ie, you just cc: some mail to the bug tracker), but there's no >> information about exactly how to use it. > > Depends on what exactly you are looking for... > > * that feature relies on finding a valid bugid in the subject, if it > finds one it will add the email ass a comment > * if you would prefer something like nnnnnn-bug@tracker.postgresql.org > for adding to existing bugs, that would be a trivial thing to add as a > feature(have the MTA split the localpart and pass it as a parameter in > the pipe-transport to the email_in.pl script) > * the challenge is more about creating "new" bugs, because for that you > need a bz account (or maybe a community account in our case) by default. > We could certainly modify the feature so that it will autocreate bz > accounts as soon as we see a new emailaddress sending email in but that > will be fairly hard to control spamwise. Yikes. (On the very last point there) But. I get the feeling we're approaching this backwards. Wouldn't the normal way to do it be to define the workflow we *want*, and then figure out which bugtracker works for that or requires the least changes for that, rather than to try to figure out which bugtracker we want and then see how much we have to change our workflow to match? The previous way is kind of what we did with the CF app, and while I have some things I want fixed in that one they are details - the process seems to work fine. So in order to start a brand new bikeshed to paint on, have we even considered a very trivial workflow like letting the bugtracker actually *only* track our existing lists and archives. That would mean: * Mailing lists are *primary*, and the mailing list archives are *primary* (yes, this probably requires a fix to the archives, but that really is a different issue) * New bugs are added by simply saying "this messageid represents a thread that has this bug in it", and all the actual contents are pulled from the archives * On top of this, the bug just tracks metadata - such as open/closed more or less. It does *not* track the actual contents at all. * Bugs registered through the bugs form would of course automatically add such a messageid into the tracker. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On mån, 2011-05-30 at 22:17 -0400, Tom Lane wrote:
> Christopher Browne <cbbrowne@gmail.com> writes:
> > On 2011-05-30 4:31 PM, "Peter Eisentraut" <peter_e@gmx.net> wrote:
> >> Based on that, and past discussions, and things we've tried in the past,
> >> and gut feeling, and so on, it looks like Request Tracker would appear
> >> to be the next best thing to consider trying out. What do people think
> >> about that?
>
> > I'd be more optimistic that debbugs, or an adaption thereof, might more
> > nearly fit into the workflow.
>
> Yeah, that's my impression as well.
I'm very familiar with debbugs, so if we'd use that, I would hit the
ground running.
But a few things to consider:
* You would probably need a lot of manpower to customize and maintain this thing. And you'd be dealing with
lotsof unfamiliar technology. * Only very few people in Debian know the internals of this thing, so
don'texpect much timely help. * The actual workflow in Debian doesn't only consist of debbugs, but a bunch of
adhoc 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
mightexpect. One of the better ways nowadays to search for bugs in Debian is actually the UDD, which is a
dumpof the bug database imported into a PostgreSQL instance. See previous point. * Actually, a number of
teamsin Debian use Request Tracker as well (see http://wiki.debian.org/rt.debian.org). I don't know why,
justsaying.
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@gmx.net> wrote: > On tis, 2011-05-31 at 10:36 +0200, Magnus Hagander wrote: >> I get the feeling we're approaching this backwards. Wouldn't the >> normal way to do it be to define the workflow we *want*, and then >> figure out which bugtracker works for that or requires the least >> changes for that, rather than to try to figure out which bugtracker we >> want and then see how much we have to change our workflow to match? > > Maybe you are assuming that there is a single workflow that everyone > wants. So far we know that most people want to work by email and want > to know that a bug is closed. Is there more detail than that that we > can extract? Yeah, there might definitely be more than one. >> So in order to start a brand new bikeshed to paint on, have we even >> considered a very trivial workflow like letting the bugtracker >> actually *only* track our existing lists and archives. That would >> mean: >> >> * Mailing lists are *primary*, and the mailing list archives are >> *primary* (yes, this probably requires a fix to the archives, but that >> really is a different issue) >> * New bugs are added by simply saying "this messageid represents a >> thread that has this bug in it", and all the actual contents are >> pulled from the archives >> * On top of this, the bug just tracks metadata - such as open/closed >> more or less. It does *not* track the actual contents at all. >> * Bugs registered through the bugs form would of course automatically >> add such a messageid into the tracker. > > Well, that is not a workflow either, it's approaching the issue by > proposing an implementation. Nothing says that an existing or new Um, good point. I still stand by my argument though, even if I'm arguing against myself :-) > system doesn't work exactly like that. I would be concerned about the > search capabilities of such a system, however. We already have a search system that works reasonably well for the archives... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
From: "Robert Haas" <robertmhaas@gmail.com> > It might be useful, in this situation, for the OP to add this patch to > the CommitFest application. > > https://commitfest.postgresql.org/action/commitfest_view/open "Greg Smith" <greg@2ndQuadrant.com> wrote in message news:4DE1A8E7.1030601@2ndQuadrant.com... > Discussion here seems to have wandered far away from useful suggestions > for you, let's see if that's possible to return to that. Best way to > confirm when a bug is resolved is to subscribe to the pgsql-committers > mailing list. If a commit for this fix appears, odds are good the > original bug number will be referenced. Even if it isn't, you may > recognize it via its description. Until you see that, the bug is almost > certainly still open. > > Bugs that are considered to impact the current version under development > are sometimes listed at http://wiki.postgresql.org/wiki/Open_Items > Adding a bug to there that's not really specific to the new version may > not be considered good form by some. It is the closest thing to an open > bug tracker around though, and adding items to there means they won't be > forgotten about; it's checked regularly by developers considering when > it's a good time to release another alpha or beta. Thank you. I understood that it's the best and perhaps only way to search the pgsql-committers mail archive periodically. I would be happy if some bug/issue tracker could kindly notify the issuer of status changes via email. I'll add my patch to either of CommitFest or Open Items list a few days later. (But I'm reluctant to pollute those pages with bug fixes which apply to previous versions. That can't be helped.) Regards MauMau
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@dunslane.net> wrote: > > > On 05/31/2011 06:41 AM, Magnus Hagander wrote: >> >> We already have a search system that works reasonably well for the >> archives... >> > > I trust this weas a piece of sarcasm. I spoke to more than a few people at > pgcon and nobody had a good word to say about the search system on the > archives. Well, it's tsearch. And I've heard nobody say anything else than that it's *a lot* better than what we had before. But sure, it can probably be improved. But what people are then basically asying is that tsearch isn't good enough for searching. Which is too bad, but may be so, and in that case we need to fix *that*, rather than build Yet Another Service To Do The Same Thing Slightly Differently. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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@dunslane.net> wrote: > > > On 05/31/2011 04:01 AM, Peter Eisentraut wrote: >> >> On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote: >>> >>> One of the conclusions the study group came to was that there should >>> be good integration between the tracker system and the SCM. That was >>> in the days before distributed SCMs were common, and in a commercial >>> context, so I'm not sure how well our reasoning would stand up for the >>> current context, but I see it's been mentioned elsewhere and I think >>> it's a significant consideration, at least. >> >> What kind of functionality would (good) SCM integration provide? >> > > > Well, the most obvious one is that when a commit (or merge or push) is made > that fixes a bug, the bug is annotated and its status updated. I know I've > wasted plenty of time in the past first hunting for bugs and then hunting > for the fixes, which aren't always clear from the commit messages. As long as we properly track email, we don't actually need a direct integration with the SCM for this - since we send the commit message out to the -committers list anyway, we just need to pick it up there. > In a more centralized system you can also have fairly tightly integrated > workflow (e.g. you can have the tracker open a branch when a bug is > assigned, and you can prevent one being created without an issue being > assigned) but that doesn't seem like such a good fit for us, nor for anyone > using a distributed system like git. You could also argue that it's a bad > thing for commercial organizations, but that's a debate for another place. > The reason we wanted such a thing is that we were spending significant time > managing the workflow issues, and doing tidy up. Yeah, that does sound like a very bad idea *for us*. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, May 31, 2011 at 02:58:02PM +0200, Magnus Hagander wrote: > On Tue, May 31, 2011 at 14:44, Andrew Dunstan <andrew@dunslane.net> wrote: > > > > > > On 05/31/2011 06:41 AM, Magnus Hagander wrote: > >> > >> We already have a search system that works reasonably well for the > >> archives... > >> > > > > I trust this weas a piece of sarcasm. I spoke to more than a few people at > > pgcon and nobody had a good word to say about the search system on the > > archives. > > Well, it's tsearch. And I've heard nobody say anything else than that > it's *a lot* better than what we had before. > > But sure, it can probably be improved. But what people are then > basically asying is that tsearch isn't good enough for searching. > Which is too bad, but may be so, and in that case we need to fix > *that*, rather than build Yet Another Service To Do The Same Thing > Slightly Differently. > > -- > Magnus Hagander > Me: http://www.hagander.net/ > Work: http://www.redpill-linpro.com/ > I do agree that the current archive search is much, much better than the searching before the upgrade. I would be interested in taking a look at some open source projects with a "good" search engine. Most projects have search engines that are true exercises in frustration by pulling either apparently everything or next to nothing and nothing in between. If there is a good one to look at maybe we can do some tweaking our search engine to improve it. Regards, Ken
On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote: >> I have used RT and I found that the >> web interface was both difficult to use and unwieldly for tickets >> containing large numbers of messages. Maybe those those things have >> been improved, but frankly if RT or Bugzilla is the best we can come >> up with then I'd rather not have a bug tracker at all. > > Given that you have been one of the people calling for a bug tracker, > and these are the two most widely used systems available, what's wrong > with them and what else would you suggest? IIRC, both of them think that you should log into the web interface to send emails (which, in the case of Bugzilla, don't permit replies), rather than sending emails that show up in the web interface. But the web interface is, at least in RT, also seems to be pretty rudimentary. Suppose you have a thread with 40 emails in it. View that thread in Gmail. Now view it in RT. In RT, you will notice that there's no way to unexpand emails, and all of the data is loaded with the page, so you sit there for half a minute waiting for everything to load. There's also no suppression of duplicated or quoted meterial, as Gmail does. It's usable, I guess, but it's a long way from state-of-the-art. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus@hagander.net> wrote: > I get the feeling we're approaching this backwards. Wouldn't the > normal way to do it be to define the workflow we *want*, and then > figure out which bugtracker works for that or requires the least > changes for that, rather than to try to figure out which bugtracker we > want and then see how much we have to change our workflow to match? > The previous way is kind of what we did with the CF app, and while I > have some things I want fixed in that one they are details - the > process seems to work fine. > > So in order to start a brand new bikeshed to paint on, have we even > considered a very trivial workflow like letting the bugtracker > actually *only* track our existing lists and archives. That would > mean: > > * Mailing lists are *primary*, and the mailing list archives are > *primary* (yes, this probably requires a fix to the archives, but that > really is a different issue) > * New bugs are added by simply saying "this messageid represents a > thread that has this bug in it", and all the actual contents are > pulled from the archives > * On top of this, the bug just tracks metadata - such as open/closed > more or less. It does *not* track the actual contents at all. > * Bugs registered through the bugs form would of course automatically > add such a messageid into the tracker. That's pretty much exactly what I think would be most useful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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 existingbug. cheers andrew
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> So in order to start a brand new bikeshed to paint on, have we even
>> considered a very trivial workflow like letting the bugtracker
>> actually *only* track our existing lists and archives. That would
>> mean:
>>
>> * Mailing lists are *primary*, and the mailing list archives are
>> *primary* (yes, this probably requires a fix to the archives, but that
>> really is a different issue)
>> * New bugs are added by simply saying "this messageid represents a
>> thread that has this bug in it", and all the actual contents are
>> pulled from the archives
>> * On top of this, the bug just tracks metadata - such as open/closed
>> more or less. It does *not* track the actual contents at all.
>> * Bugs registered through the bugs form would of course automatically
>> add such a messageid into the tracker.
> That's pretty much exactly what I think would be most useful.
I kinda wonder why the CF app doesn't work like that, actually.
(Yeah, I know the poor thread linking in the archives is an issue.)
regards, tom lane
On Tue, May 31, 2011 at 09:33:33AM -0400, Robert Haas wrote: > On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > > On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote: > >> I have used RT and I found that the > >> web interface was both difficult to use and unwieldly for tickets > >> containing large numbers of messages. Maybe those those things have > >> been improved, but frankly if RT or Bugzilla is the best we can come > >> up with then I'd rather not have a bug tracker at all. > > > > Given that you have been one of the people calling for a bug tracker, > > and these are the two most widely used systems available, what's wrong > > with them and what else would you suggest? > > IIRC, both of them think that you should log into the web interface to > send emails (which, in the case of Bugzilla, don't permit replies), > rather than sending emails that show up in the web interface. But the > web interface is, at least in RT, also seems to be pretty rudimentary. > If you use the commands-by-email with RT you can do most things with Email. > Suppose you have a thread with 40 emails in it. View that thread in > Gmail. Now view it in RT. In RT, you will notice that there's no way > to unexpand emails, and all of the data is loaded with the page, so > you sit there for half a minute waiting for everything to load. > There's also no suppression of duplicated or quoted meterial, as Gmail > does. It's usable, I guess, but it's a long way from > state-of-the-art. > You can adjust what RT will display in the interface and the latest release does include some enhanced duplicate/quoted material suppression. Note, I am not pushing for RT necessarily just trying to keep information available. Regards, Ken
Andrew Dunstan <andrew@dunslane.net> writes:
> On 05/31/2011 06:41 AM, Magnus Hagander wrote:
>> We already have a search system that works reasonably well for the archives...
> I trust this weas a piece of sarcasm. I spoke to more than a few people
> at pgcon and nobody had a good word to say about the search system on
> the archives.
Please note, though, that there is no bug tracker anywhere whose search
mechanism doesn't suck as much or more. If you're unhappy with the
search stuff the solution is to improve it, not bring in another bad
mechanism.
regards, tom lane
On Tue, May 31, 2011 at 16:21, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > "ktm@rice.edu" <ktm@rice.edu> wrote: > >> maybe we can do some tweaking our search engine to improve it. > > A custom dictionary to carefully add a few synonyms might go a long > way. I often need to try a number of permutations of likely words > to get relevant hits. If you can provide one, please do :-) Right now, all we have is: postgres postgres postgresql postgres pgsql postgres pg postgres postgre postgres > Including the subject line in searches, with a higher weight than > message body text, would also be great. We already do this - we set them to class "A" with setweight(). > Possibly it would help to be able to search on From or To fields > (including CC in the To). Sometimes you have some recollection who > participated in a discussion, but can't find the magic terms to get > a small result set which includes the right discussion. This we don't do -w e store the From field, but we don't index it. And we don't do anything with the To field. So that's certainly something we could add. > I really think some pretty minor tweaks in these areas would go a > very long way toward making the archive searches more useful. Any patches are definitely welcome - you can find the search system at https://pgweb.postgresql.org/browser/trunk/portal/tools/search :-) (for the archives, you're probably most interested in classes/ArchiveIndexer.class.php and the sql/functions.sql file) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
"ktm@rice.edu" <ktm@rice.edu> wrote: > maybe we can do some tweaking our search engine to improve it. A custom dictionary to carefully add a few synonyms might go a long way. I often need to try a number of permutations of likely words to get relevant hits. Including the subject line in searches, with a higher weight than message body text, would also be great. Possibly it would help to be able to search on From or To fields (including CC in the To). Sometimes you have some recollection who participated in a discussion, but can't find the magic terms to get a small result set which includes the right discussion. I really think some pretty minor tweaks in these areas would go a very long way toward making the archive searches more useful. -Kevin
On Tue, May 31, 2011 at 09:36:00AM -0400, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > On 05/31/2011 06:41 AM, Magnus Hagander wrote: > >> We already have a search system that works reasonably well for the archives... > > > I trust this weas a piece of sarcasm. I spoke to more than a few people > > at pgcon and nobody had a good word to say about the search system on > > the archives. > > Please note, though, that there is no bug tracker anywhere whose search > mechanism doesn't suck as much or more. If you're unhappy with the > search stuff the solution is to improve it, not bring in another bad > mechanism. > +1 Ken
Magnus Hagander <magnus@hagander.net> wrote: > Any patches are definitely welcome - you can find the search > system at > https://pgweb.postgresql.org/browser/trunk/portal/tools/search > :-) > > (for the archives, you're probably most interested in > classes/ArchiveIndexer.class.php and the sql/functions.sql file) I stashed this away for future reference; I'll take a look when I have a bit more free time. I suppose the first thing is to search the archives for posts about not being able to find some discussion in the archives, where someone then provides search criteria or a link.. I know I've seen a bunch of those -- I just hope I can find them... ;-) -Kevin
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
On Tue, May 31, 2011 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> So in order to start a brand new bikeshed to paint on, have we even >>> considered a very trivial workflow like letting the bugtracker >>> actually *only* track our existing lists and archives. That would >>> mean: >>> >>> * Mailing lists are *primary*, and the mailing list archives are >>> *primary* (yes, this probably requires a fix to the archives, but that >>> really is a different issue) >>> * New bugs are added by simply saying "this messageid represents a >>> thread that has this bug in it", and all the actual contents are >>> pulled from the archives >>> * On top of this, the bug just tracks metadata - such as open/closed >>> more or less. It does *not* track the actual contents at all. >>> * Bugs registered through the bugs form would of course automatically >>> add such a messageid into the tracker. > >> That's pretty much exactly what I think would be most useful. > > I kinda wonder why the CF app doesn't work like that, actually. > (Yeah, I know the poor thread linking in the archives is an issue.) I thought this pretty much WAS how the CF app works, except that it's for patches rather than bugs. Perhaps it could be extended to also track bugs... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, May 31, 2011 at 9:59 AM, Andrew Dunstan <andrew@dunslane.net> wrote: > On 05/31/2011 09:33 AM, Robert Haas wrote: >> >> IIRC, both of them think that you should log into the web interface to >> send emails (which, in the case of Bugzilla, don't permit replies), >> rather than sending emails that show up in the web interface. > > I think you probably need to look at Bugzilla again. Here's what the current > feature page at <http://www.bugzilla.org/features/#email-in> says: > > In addition to the web interface, you can send Bugzilla an email > that will create a new bug, or will modify an existing bug. That's possible. I haven't used it in about 5 years, and I suppose that makes my opinion of it hideously dated. I wouldn't like it if someone judged PostgreSQL based on what 8.1 can do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from Joe Abbate's message of mar may 31 10:43:07 -0400 2011: > I have a web crawler for a website I maintain that I could modify to > crawl through the archives of -bugs, say from 5 Dec 2003 where the first > bug with the new format appears, and capture the structured data > (reference, logged by, email address, PG version, OS, description, and > message URL) into a table, for every message whose subject starts with > "BUG #", and capture each message URL for any message that has "BUG #" > somewhere in the subject, in a second table. > > I presume the tables could be used even if it's decided to go with > something like RT or BZ, but before I spend a couple of hours on this > I'd like see some ayes or nays. Useful or not? I think this would be easier if you crawled the monthly mboxen instead of the web archives. It'd be preferable to use message-ids to identify messages rather than year-and-month based URLs. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 31, 2011 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I kinda wonder why the CF app doesn't work like that, actually.
>> (Yeah, I know the poor thread linking in the archives is an issue.)
> I thought this pretty much WAS how the CF app works, except that it's
> for patches rather than bugs. Perhaps it could be extended to also
> track bugs...
Well, the point is you have to go and manually fool around with the web
interface to enter something into CF, rather than just cc'ing it on your
patch or review email.
regards, tom lane
Hola Alvaro, On 05/31/2011 11:38 AM, Alvaro Herrera wrote: > I think this would be easier if you crawled the monthly mboxen instead > of the web archives. It'd be preferable to use message-ids to identify > messages rather than year-and-month based URLs. I can capture the message-ids, as well as the message date, from crawling the web archives. If the tracker has some kind of web interface, I assume a link such as http://archives.postgresql.org/pgsql-bugs/2003-12/msg00046.php would be easier to follow than <20031205173035.GA16741@wolff.to> unless the mboxes are stored in an easily accessible form by message-id (i.e., outside the web archives). Plus having the web link allows eventual tracking of messages outside of -bugs. Joe
On Tue, May 31, 2011 at 12:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, May 31, 2011 at 10:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> I kinda wonder why the CF app doesn't work like that, actually. >>> (Yeah, I know the poor thread linking in the archives is an issue.) > >> I thought this pretty much WAS how the CF app works, except that it's >> for patches rather than bugs. Perhaps it could be extended to also >> track bugs... > > Well, the point is you have to go and manually fool around with the web > interface to enter something into CF, rather than just cc'ing it on your > patch or review email. Oh, I see. Well, that could probably be changed. One thing to think about with the current system is that typically only the most relevant links get added, as opposed to the entire thread. Now, the bad news is that means things often don't get added at all. The good news is that typically when people do update it, the add only the relevant things, thus avoiding filling it up with a massive amount of crap. I don't know whether that works out to a bug or a feature. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Joe Abbate <jma@freedomcircle.com> wrote: > I assume a link such as > > http://archives.postgresql.org/pgsql-bugs/2003-12/msg00046.php > > would be easier to follow than > > <20031205173035.GA16741@wolff.to> The point is that the community seems to have reached a consensus that they would rather use this URL for the above message: http://archives.postgresql.org/message-id/20031205173035.GA16741@wolff.to -Kevin
Excerpts from Kevin Grittner's message of mar may 31 12:41:59 -0400 2011: > Joe Abbate <jma@freedomcircle.com> wrote: > > > I assume a link such as > > > > http://archives.postgresql.org/pgsql-bugs/2003-12/msg00046.php > > > > would be easier to follow than > > > > <20031205173035.GA16741@wolff.to> > > The point is that the community seems to have reached a consensus > that they would rather use this URL for the above message: > > http://archives.postgresql.org/message-id/20031205173035.GA16741@wolff.to Yeah, I keep dreaming that one day we will get rid of the silly monthly partitioning of archives. Those URLs will eventually be legacy -- existing ones will continue to work, but new messages will not (may not) get them any longer. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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
On Tue, May 31, 2011 at 19:10, Joe Abbate <jma@freedomcircle.com> wrote: > On 05/31/2011 12:41 PM, Kevin Grittner wrote: >> The point is that the community seems to have reached a consensus >> that they would rather use this URL for the above message: >> >> http://archives.postgresql.org/message-id/20031205173035.GA16741@wolff.to > > OK, as I said, I can still capture the message-id's by crawling -bugs by > year-month. Just to be clear, crawling the current archives for this info is probably the easiest part of the whole project. In fact, the majority of the information you'd need is *already* in a postgresql database on search.postgresql.org. So - let's start in the other end, and get back to this if/when it's needed. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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 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
Excerpts from Joshua D. Drake's message of mar may 31 12:32:43 -0400 2011: > > Given that you have been one of the people calling for a bug tracker, > > and these are the two most widely used systems available, what's wrong > > with them and what else would you suggest? > > Just FYI, CMD uses redmine and so far it is the best we have found. It > isn't perfect certainly but overall it does a nice job. It supports > email integration as well as plugins (we have even written a couple). I certainly wouldn't suggest that Redmine wouldn't cause a change in workflow though. > Alvaro has also brought up the system that Debian uses which is actually > email based versus web based. Yeah, that's debbugs, which has been mentioned elsewhere in this thread. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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
On Sun, May 29, 2011 at 4:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> That doesn't mean that better integration cannot be worked on later, but >> this illusion that a bug tracker must have magical total awareness of >> the entire flow of information in the project from day one is an >> illusion and has blocked this business for too long IMO. > > If it has only a partial view of the set of bugs being worked on, it's > not going to meet the goals that are being claimed for it. > > I don't doubt that somebody could run around and link every discussion > about a bug into the tracker. I'm just dubious that that actually > *will* happen with enough reliability to make the tracker more useful > than a mailing-list search. > > In the end, I think that requests for a tracker mostly come from people > who are not part of this community, or at least not part of its mailing > lists (which is about the same thing IMO). If they submitted a bug > report via the lists, they're generally going to get replies via email, > and that seems sufficient to me. But if they submitted a report via the > web form, they might well be expecting that they can track what's going > on with it on a web page. And that's not unreasonable. But we could > fix that without any changes at all in our work processes. Just have > the webform add a "cc: bugbot-bugNNNN@postgresql.org" to each submitted > email, and set up a bot to collect the traffic and display it on a > suitable web page. (Spam filtering left as an exercise for the reader.) The part of the discussion we've missed so far is that bug trackers are usually about the blame functionality and measurement of response times. We're a responsive and diligent community, so I see no problem here that wouldn't be solved simply by using better static URLs. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Tue, May 31, 2011 at 19:59, Joe Abbate <jma@freedomcircle.com> wrote: > On 05/31/2011 01:13 PM, Magnus Hagander wrote: >> Just to be clear, crawling the current archives for this info is >> probably the easiest part of the whole project. In fact, the majority >> of the information you'd need is *already* in a postgresql database on >> search.postgresql.org. > > Does that database have the bug number, PG version and OS as separate > columns, or is it simply an index over all the messages across all the > lists? I think a table just of bug info would be useful at this time, > e.g., to load a potential candidate. However, the message database --if > it includes the message bodies-- would obviously be easier to work with > than web crawling. It does not have all those details, but it has the sender, subject and bodies broken out. So it's definitely an easier starting point. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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
On Tue, May 31, 2011 at 19:37, Peter Eisentraut <peter_e@gmx.net> wrote: > On tis, 2011-05-31 at 14:58 +0200, Magnus Hagander wrote: >> But sure, it can probably be improved. But what people are then >> basically asying is that tsearch isn't good enough for searching. > > For one thing, there should be more structured search possibilities, > such as by date or author or subject only etc. Nothing that tsearch has > anything to do with. All those sound like things that should be easily doable on top of the current database. Care to create a wiki page with a suggested interface? (Unless oyu want to code up an actual patch for it :P) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
2011/5/31 Alvaro Herrera <alvherre@commandprompt.com>: > Excerpts from Joshua D. Drake's message of mar may 31 12:32:43 -0400 2011: >> Alvaro has also brought up the system that Debian uses which is actually >> email based versus web based. > > Yeah, that's debbugs, which has been mentioned elsewhere in this thread. I like this one, does it have something we don't like ? it is mail oriented, have a web-interface, a search engine. It is easy to merge bugs etc... The other alternative more individual is a sieve script to filter and manage -bugs and -commiters maybe -hackers (not done, but that might not be so hard) > > -- > Álvaro Herrera <alvherre@commandprompt.com> > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
Alvaro Herrera <alvherre@commandprompt.com> writes: > Excerpts from Kevin Grittner's message of mar may 31 12:41:59 -0400 2011: >> The point is that the community seems to have reached a consensus >> that they would rather use this URL for the above message: >> >> http://archives.postgresql.org/message-id/20031205173035.GA16741@wolff.to > > Yeah, I keep dreaming that one day we will get rid of the silly monthly > partitioning of archives. Those URLs will eventually be legacy -- > existing ones will continue to work, but new messages will not (may not) > get them any longer. Check out the following POC, which needs to get migrated into a django application for the upcoming new infrastructure: http://archives.beccati.org/ It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL database. The mails threading view is even a CTE. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
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@commandprompt.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@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
2011/5/31 Josh Berkus <josh@agliodbs.com>: > All, > > Let me mention some of the reasons we as a project could use a bug > tracker which have nothing to do with actually fixing bugs. > > (1) Testing: a bug tracker could be used for beta testing instead of the > ad-hoc system I'm writing. Assuming it has the right features, of course. > > (2) User information: right now, if a user has an issue, it's very very > hard for them to answer the question "Has this already been reported > and/or fixed in a later release." This is a strong source of > frustration for business users who don't actively participate in the > community, a complaint I have heard multiple times. > > (3) Lack of a bug tracker with a web services API prevents downstream > projects (PostGIS, RHEL, Ubuntu, Django, Drupal, etc.) from linking in > PostgreSQL bug reports which affect their users. Also, because these > projects are used to bug trackers, they get confused when they need to > report a bug to us. > > (4) Because having a bug tracker is seen as standard and mainstream > among OSS projects, the fact that we don't have one is regarded as > oddball and backwards, and does result in some companies choosing not to > use PostgreSQL because we're perceived as "too weird" and > "anti-commercial". > > Where *fixing* bugs is concerned, I'm concerned that a bug tracker would > actually slow things down. I'm dubious about our ability to mobilize > volunteers for anything other than bug triage, and the fact that we > *don't* triage is an advantage in bug report responsiveness (I have > "unconfirmed" bugs for Thunderbird which have been pending for 3 years). > So I'm skeptical about bug trackers on that score. > > However, for the four non-fixing items, having some kind of bug tracker > would be a real asset to the project. I'm just not sure what kind of > bug tracker that would be. > > BTW, we talked to Debian about debbugs ages ago, and the Debian project > said that far too much of debbugs was not portable to other projects. GNU succeed to use it, it seems: http://debbugs.gnu.org/Using.html http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1 > > -- > Josh Berkus > PostgreSQL Experts Inc. > http://pgexperts.com > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
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@commandprompt.com> writes: >> http://archives.beccati.org/ >> >> It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL >> database. The mails threading view is even a CTE. > > Yeah, it's great. Last time I heard, though, Mateo wasn't open to doing > any more work on it (including fixing a bunch of bugs we found) until > the web migration to the Django stuff materialized. Yeah, given the amount of work that already went into this prototype, I guess I would have reacted about the same. I'm not sure that's the only project stuck behind the new platform migration. How can we help with this new infrastructure thing ? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Wed, Jun 1, 2011 at 10:43, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >>> http://archives.beccati.org/ >>> >>> It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL >>> database. The mails threading view is even a CTE. >> >> Yeah, it's great. Last time I heard, though, Mateo wasn't open to doing >> any more work on it (including fixing a bunch of bugs we found) until >> the web migration to the Django stuff materialized. > > Yeah, given the amount of work that already went into this prototype, I > guess I would have reacted about the same. I'm not sure that's the only > project stuck behind the new platform migration. How can we help with > this new infrastructure thing ? Actually, given a new box deployed by stefan just two or three days ago, the infrastructure side is ready. What would help at this point would be if at least one oft he *many* different people who promised to do some code review on the new website code would, you know, actually do that. (git.postgresql.org, project pgweb and pgweb-static for those interested) And of course, code improvements, not just review, is also always welcome. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 05/31/2011 05:41 PM, Alvaro Herrera wrote: > Excerpts from Josh Berkus's message of mar may 31 17:05:23 -0400 2011: > > >> BTW, we talked to Debian about debbugs ages ago, and the Debian project >> said that far too much of debbugs was not portable to other projects. >> > The good news is that the GNU folk proved them wrong, as evidenced > elsewhere in the thread. > What happened is that one of the authors got motivated (not sure why/how) to put a major amount of work into making the code portable so that sites other than Debian could use it. So past perceptions about it being really hard were correct, that's just been fixed since then. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
Josh Berkus wrote: > All, > > Let me mention some of the reasons we as a project could use a bug > tracker which have nothing to do with actually fixing bugs. > > (1) Testing: a bug tracker could be used for beta testing instead of the > ad-hoc system I'm writing. Assuming it has the right features, of course. > > (2) User information: right now, if a user has an issue, it's very very > hard for them to answer the question "Has this already been reported > and/or fixed in a later release." This is a strong source of > frustration for business users who don't actively participate in the > community, a complaint I have heard multiple times. Also, bug reporters frequently don't get any email feedback on when their bug was fixed. It is also hard to identify what major/minor release fixed a specific bug, especially if the bug was rare. > Where *fixing* bugs is concerned, I'm concerned that a bug tracker would > actually slow things down. I'm dubious about our ability to mobilize > volunteers for anything other than bug triage, and the fact that we > *don't* triage is an advantage in bug report responsiveness (I have > "unconfirmed" bugs for Thunderbird which have been pending for 3 years). > So I'm skeptical about bug trackers on that score. Yes, I agree. Too many bug systems are just a dumping-pile for bugs. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Greg Stark wrote: > On Mon, May 30, 2011 at 6:52 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > ?The number of people reading and replying to > > emails on pgsql-bugs is already insufficient, perhaps because of the > > (incorrect) perception that Tom does or will fix everything and no one > > else needs to care. ?So anything that makes it harder for people to > > follow along and participate is a non-starter IMV. > > Actually I think most of our bugs don't come in from pgsql-bugs. I > think we want to add other bugs that come up from discussions on > -hackers or -general which for whatever reason don't get immediately > fixed. Agreed. At that point the TODO list is no longer needed, perhaps. It would be nice to have a system where we could categorize items, and add "features" as well because the bug/feature distinction is often very hard to make. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > That doesn't mean that better integration cannot be worked on later, but > > this illusion that a bug tracker must have magical total awareness of > > the entire flow of information in the project from day one is an > > illusion and has blocked this business for too long IMO. > > If it has only a partial view of the set of bugs being worked on, it's > not going to meet the goals that are being claimed for it. The problem with a bug tracker that only tracks some bugs is that people will mistakenly believe the system is complete, when it is not. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Just to throw out a crazy idea, there has been talk of bug ids. What if a thread, made up of multiple message ids, was in fact the bug id, and the first message in the thread (ignoring month boundaries) was the definitive bug id, but any of the message ids could be used to represent the definitive one. That way, a message id mentioned in a commit message could track back to the definitive bug id and therefore be used to close the bug. If you think of it that way, your email stream is just a stream of threads, with a definitive bug id per thread, that is either "not a bug", "a bug", " a fix", or "other". In a way, all you need to do is for someone to add the "thread" to the bug system via email, and change its status via email. Yes, crazy, but that is kind of how I track open items in my mailbox. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
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@momjian.us> wrote: > Just to throw out a crazy idea, there has been talk of bug ids. What if > a thread, made up of multiple message ids, was in fact the bug id, and > the first message in the thread (ignoring month boundaries) was the > definitive bug id, but any of the message ids could be used to represent > the definitive one. > > That way, a message id mentioned in a commit message could track back to > the definitive bug id and therefore be used to close the bug. > > If you think of it that way, your email stream is just a stream of > threads, with a definitive bug id per thread, that is either "not a > bug", "a bug", " a fix", or "other". > > In a way, all you need to do is for someone to add the "thread" to the > bug system via email, and change its status via email. > > Yes, crazy, but that is kind of how I track open items in my mailbox. That doesn't seem crazy at all... It seems to parallel the way that distributed SCMs treat series of versions as the intersections of related repository versions, each identified by a hash code. There is one problem I see with the "definitive bug ID," which is that a thread might wind up discussing *two* problems, and it would be regrettable to discover that this got forced to be treated as a single bug. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"