Re: BugTracker (Was: Re: 8.2 features status)

bruce wrote:
> bruce wrote:
> >
> > OK, seems this should be a separate application, not done in the TODO
> > list, and I am not willing to take on that additional workload.
>
> Let me add that anyone who has CVS commit access or wants to submit
> TODO patches can keep the TODO updated in this way.

I can also give someone ssh access to my server with the ability to
modify only the TODO list.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote:
> bruce wrote:
> > bruce wrote:
> > >
> > > OK, seems this should be a separate application, not done in the TODO
> > > list, and I am not willing to take on that additional workload.
> >
> > Let me add that anyone who has CVS commit access or wants to submit
> > TODO patches can keep the TODO updated in this way.
>
> I can also give someone ssh access to my server with the ability to
> modify only the TODO list.

I've never submitted patches for the TODO because it seems pretty silly
to go through that much work just to add one line to a file, but being
able to change it directly would be a good compromise. I'd be happy to
help.

Something else that bugs me about the current TODO process is there's a
lot of ideas that get brought up but never make it on there. Certainly
a lot of them aren't worth putting on there, but there's plenty of items
that get left on the floor. It would be nice if there was a better way
to deal with these ideas.

One possibility: have a 'holding area' (perhaps on a Wiki) where users
could add use-cases for these ideas. If there's 'enough demand' (however
one defines that), they get promoted to the TODO. Note that this is
something geared towards users... things that are obviously useful to
-hackers tend to get on the list.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

Jim C. Nasby wrote:
> On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote:
> > bruce wrote:
> > > bruce wrote:
> > > >
> > > > OK, seems this should be a separate application, not done in the TODO
> > > > list, and I am not willing to take on that additional workload.
> > >
> > > Let me add that anyone who has CVS commit access or wants to submit
> > > TODO patches can keep the TODO updated in this way.
> >
> > I can also give someone ssh access to my server with the ability to
> > modify only the TODO list.
>
> I've never submitted patches for the TODO because it seems pretty silly
> to go through that much work just to add one line to a file, but being
> able to change it directly would be a good compromise. I'd be happy to
> help.
>
> Something else that bugs me about the current TODO process is there's a
> lot of ideas that get brought up but never make it on there. Certainly
> a lot of them aren't worth putting on there, but there's plenty of items
> that get left on the floor. It would be nice if there was a better way
> to deal with these ideas.

I have to be selective because having items we aren't sure we want on
there isn't helpful.

> One possibility: have a 'holding area' (perhaps on a Wiki) where users
> could add use-cases for these ideas. If there's 'enough demand' (however
> one defines that), they get promoted to the TODO. Note that this is
> something geared towards users... things that are obviously useful to
> -hackers tend to get on the list.

Yea, that would be interesting, like a pending TODO item list.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Wednesday 09 August 2006 12:12, Bruce Momjian wrote:
> > One possibility: have a 'holding area' (perhaps on a Wiki) where users
> > could add use-cases for these ideas. If there's 'enough demand' (however
> > one defines that), they get promoted to the TODO. Note that this is
> > something geared towards users... things that are obviously useful to
> > -hackers tend to get on the list.
>
> Yea, that would be interesting, like a pending TODO item list.

Wouldn't a thread reply saying something like "Bruce, can we add this as a
TODO with the following wording: blah blah blah" likely suffice?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Robert Treat wrote:
> On Wednesday 09 August 2006 12:12, Bruce Momjian wrote:
>>> One possibility: have a 'holding area' (perhaps on a Wiki) where users
>>> could add use-cases for these ideas. If there's 'enough demand' (however
>>> one defines that), they get promoted to the TODO. Note that this is
>>> something geared towards users... things that are obviously useful to
>>> -hackers tend to get on the list.
>> Yea, that would be interesting, like a pending TODO item list.
>
> Wouldn't a thread reply saying something like "Bruce, can we add this as a
> TODO with the following wording: blah blah blah" likely suffice?
>

Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't see
why that is hard or onerous). Plus it is seen by a wide audience, some
of whom might not be tracking any wiki (very likely if there end up
being several wiki's....)

On that note, one nice feature of the current setup, is that the only
place you need to look is the TODO, which then (hopefully) points you to
a detail or url for more info. To have to check the TODO *and* the wiki
is just one more thing to forget IMHO.

Cheers

Mark

Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
> Robert Treat wrote:
>> Wouldn't a thread reply saying something like "Bruce, can we add this as a
>> TODO with the following wording: blah blah blah" likely suffice?

That's pretty much how it's done now ...

> Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't see
> why that is hard or onerous). Plus it is seen by a wide audience, some
> of whom might not be tracking any wiki (very likely if there end up
> being several wiki's....)

Yeah, the main problem I have with TODO-on-a-wiki is the question of
quality control. I've been heard to complain that "the TODO list
consists of everything Bruce thinks is a good idea", but for the most
part things don't get onto TODO without some rough consensus on the
mailing lists --- at least about the nature of the problem, if not
the exact shape of the solution. I'm worried about a wiki having pages
that have not been peer-reviewed at all. In some respects that wouldn't
matter, but what of our hypothetical newbie developer coming along and
taking entries at face value? If you don't know the project well enough
to recognize bogus entries, you could still end up wasting your time
on silly ideas that will get rejected once seen by a wider audience.

regards, tom lane

Tom Lane wrote:

> Yeah, the main problem I have with TODO-on-a-wiki is the question of
> quality control. I've been heard to complain that "the TODO list
> consists of everything Bruce thinks is a good idea", but for the most
> part things don't get onto TODO without some rough consensus on the
> mailing lists --- at least about the nature of the problem, if not
> the exact shape of the solution. I'm worried about a wiki having pages
> that have not been peer-reviewed at all. In some respects that wouldn't
> matter, but what of our hypothetical newbie developer coming along and
> taking entries at face value? If you don't know the project well enough
> to recognize bogus entries, you could still end up wasting your time
> on silly ideas that will get rejected once seen by a wider audience.

To bring up PHP again:
http://oss.backendmedia.com/PhP52

This is the todo list for the upcoming 5.2.0 release that is currently
in RC1. Most of the todo items in PHP do not need much detail, so this
list does not carry much more information than Bruce's list. The wiki
has support for ACL's, so I have given various trusted people direct
access. Some developers however rely on me for updating the items.

As you can see there is a confirmed (as in the release manager has oked
the todo) and an under discussion as well as a future 5.x release
section. We already have a separate todo list for php 6.

A todo list that illustrates the ability to attach more information for
a given todo item is my PEAR::MDB2 list in the same wiki:
http://oss.backendmedia.com/MDB2/ToDo

regards,
Lukas

First, +1 on Josh B.'s point about trying out Trac, since it's
already up and running. Josh D., can you just turn that on? (BTW, is
trac linked off http://commandprompt.com anywhere? I had to google to
find it yesterday...)

On Aug 9, 2006, at 11:34 PM, Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
>> Robert Treat wrote:
>>> Wouldn't a thread reply saying something like "Bruce, can we add
>>> this as a
>>> TODO with the following wording: blah blah blah" likely suffice?
>
> That's pretty much how it's done now ...

Robert missed the point I was making... there is value in keeping
track of ideas that may not have enough consensus to be a valid TODO
yet, but could still be useful.

>> Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't
>> see
>> why that is hard or onerous). Plus it is seen by a wide audience,
>> some
>> of whom might not be tracking any wiki (very likely if there end up
>> being several wiki's....)
>
> Yeah, the main problem I have with TODO-on-a-wiki is the question of
> quality control. I've been heard to complain that "the TODO list
> consists of everything Bruce thinks is a good idea", but for the most
> part things don't get onto TODO without some rough consensus on the
> mailing lists --- at least about the nature of the problem, if not
> the exact shape of the solution. I'm worried about a wiki having
> pages
> that have not been peer-reviewed at all. In some respects that
> wouldn't
> matter, but what of our hypothetical newbie developer coming along and
> taking entries at face value? If you don't know the project well
> enough
> to recognize bogus entries, you could still end up wasting your time
> on silly ideas that will get rejected once seen by a wider audience.

Agreed... there needs to be enough consensus and 'critical mass'
before something becomes an official TODO. Because of that, we
shouldn't allow anyone to edit the TODO wiki (though I do think we
shouldn't put the entire responsibility on Bruce).

A nice thing about a wiki is it makes it easy for people to
collectively work on a use-case and design for a TODO item. One thing
that could come out of this is the expectation that TODO items that
aren't "inherently obvious" (however you define that) must come with
X amount of documentation (use cases, design, what-have-you). This
isn't something that should replace discussion on the mailing lists,
but I think that being able to point to a wiki page with the
finalized info about a TODO item is a lot better than pointing at
list archives that are spread all over.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

Jim Nasby wrote:
> First, +1 on Josh B.'s point about trying out Trac, since it's
> already up and running. Josh D., can you just turn that on? (BTW, is
> trac linked off http://commandprompt.com anywhere? I had to google to
> find it yesterday...)

I just noticed that the code repository on that Trac is broken in more
ways than I had realized. For starters it doesn't seem to have the 8.1
branch or tags (apparently it's out of date).

Doesn't Trac have a CVS plugin? It will just cause confusion to have a
SVN repo that doesn't reflect reality -- which it wouldn't even if it
weren't broken.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Jim Nasby wrote:
>> First, +1 on Josh B.'s point about trying out Trac, since it's
>> already up and running. Josh D., can you just turn that on? (BTW, is
>> trac linked off http://commandprompt.com anywhere? I had to google to
>> find it yesterday...)
>
> I just noticed that the code repository on that Trac is broken in more
> ways than I had realized. For starters it doesn't seem to have the 8.1
> branch or tags (apparently it's out of date).

It doesn't?

http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql

What are you looking at Alvaro?

>
> Doesn't Trac have a CVS plugin?

No, like the rest of the world, Trac has moved on from CVS ;)

> It will just cause confusion to have a
> SVN repo that doesn't reflect reality

Well sure... but again... what are you looking at, because it looks fine
to me?

And to be clear, I would only expect that this would be used as a
reference, that is all. The ability to link from the wiki directly to a
source file or changeset could be useful.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Alvaro Herrera wrote:
> Jim Nasby wrote:
>> First, +1 on Josh B.'s point about trying out Trac, since it's
>> already up and running. Josh D., can you just turn that on? (BTW, is
>> trac linked off http://commandprompt.com anywhere? I had to google to
>> find it yesterday...)

Oh and answer Jim's question. No isn't linked of www.cmd... why? I have
no idea ;) It should be on our /community page.

>
> I just noticed that the code repository on that Trac is broken in more
> ways than I had realized. For starters it doesn't seem to have the 8.1
> branch or tags (apparently it's out of date).
>
> Doesn't Trac have a CVS plugin? It will just cause confusion to have a
> SVN repo that doesn't reflect reality -- which it wouldn't even if it
> weren't broken.
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Thu, 2006-08-10 at 17:33 -0700, Joshua D. Drake wrote:
> No, like the rest of the world, Trac has moved on from CVS ;)

There is CVSTrac (www.cvstrac.org), which actually predates Trac.

However, is there a reason to use Trac beyond the fact that it is
already setup? ISTM we only need a wiki, and don't need the other
features of Trac, such as the bug tracker.

-Neil

Neil Conway wrote:
> On Thu, 2006-08-10 at 17:33 -0700, Joshua D. Drake wrote:
>> No, like the rest of the world, Trac has moved on from CVS ;)
>
> There is CVSTrac (www.cvstrac.org), which actually predates Trac.
>
> However, is there a reason to use Trac beyond the fact that it is
> already setup? ISTM we only need a wiki, and don't need the other
> features of Trac, such as the bug tracker.

Well that is certainly the question but the bug tracker could easily
turn into a todo list as well. It is a very powerful tool that is
relatively flexible.

Joshua D. Drake

>
> -Neil
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Jim Nasby wrote:
> First, +1 on Josh B.'s point about trying out Trac, since it's
> already up and running. Josh D., can you just turn that on? (BTW, is
> trac linked off http://commandprompt.com anywhere? I had to google to
> find it yesterday...)
>
> On Aug 9, 2006, at 11:34 PM, Tom Lane wrote:
> > Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
> >> Robert Treat wrote:
> >>> Wouldn't a thread reply saying something like "Bruce, can we add
> >>> this as a
> >>> TODO with the following wording: blah blah blah" likely suffice?
> >
> > That's pretty much how it's done now ...
>
> Robert missed the point I was making... there is value in keeping
> track of ideas that may not have enough consensus to be a valid TODO
> yet, but could still be useful.

It seems some people like the authoritative TODO list, and others want a
TODO wiki that they can add stuff to without having to get community
buy-in. I have trouble seeing how the wiki doesn't just end up being a
blog of ideas, but I see no harm in it as long as it is clear the items
haven't passed community review.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

>
> It seems some people like the authoritative TODO list, and others want a
> TODO wiki that they can add stuff to without having to get community
> buy-in. I have trouble seeing how the wiki doesn't just end up being a
> blog of ideas, but I see no harm in it as long as it is clear the items
> haven't passed community review.

I think it is a combination of the two. A wiki could be used to discuss
ideas for todos, it could be used to describe TODOs in actual detail, it
could used (in conjunction with Trac) to be able to document dependecies
for todos... etc.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Joshua D. Drake wrote:
> >
> > It seems some people like the authoritative TODO list, and others want a
> > TODO wiki that they can add stuff to without having to get community
> > buy-in. I have trouble seeing how the wiki doesn't just end up being a
> > blog of ideas, but I see no harm in it as long as it is clear the items
> > haven't passed community review.
>
> I think it is a combination of the two. A wiki could be used to discuss
> ideas for todos, it could be used to describe TODOs in actual detail, it
> could used (in conjunction with Trac) to be able to document dependecies
> for todos... etc.

But what is it likely to do? I don't think much, but if we can shut it
down if we decide it isn't of value (unlike gborg which can't be shut
down), I think it is fine to try.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote:

> I think it is a combination of the two. A wiki could be used to discuss
> ideas for todos, it could be used to describe TODOs in actual detail, it
> could used (in conjunction with Trac) to be able to document dependecies
> for todos... etc.

A wiki for *discussion*? I thought email was for that. A wiki is nice to
work toghether on a document (in some circumstances).

--
__________________________________________________
"Nothing is as subjective as reality"
Reinoud van Leeuwen reinoud(dot)v(at)n(dot)leeuwen(dot)net
http://www.xs4all.nl/~reinoud
__________________________________________________

Reinoud van Leeuwen wrote:

> On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote:
>
>> I think it is a combination of the two. A wiki could be used to discuss
>> ideas for todos, it could be used to describe TODOs in actual detail, it
>> could used (in conjunction with Trac) to be able to document dependecies
>> for todos... etc.
>
> A wiki for *discussion*? I thought email was for that. A wiki is nice to
> work toghether on a document (in some circumstances).

I dont he meant that. A wiki is a good place to summarize an email
discussion, not to actually hold a discussion on the wiki (I have seen
it done though .. and its not pretty).

regards,
Lukas

Neil Conway napsal(a):

> However, is there a reason to use Trac beyond the fact that it is
> already setup? ISTM we only need a wiki, and don't need the other
> features of Trac, such as the bug tracker.

I do not agree. How you determine what release fixes the bug now? We
have web page and mailing list for bug reporting but there is not any
relation between bug, patch and release(s). I think bug tracking is
necessary if we want move forward.

Zdenek

Joshua D. Drake wrote:
> Alvaro Herrera wrote:
> >Jim Nasby wrote:
> >>First, +1 on Josh B.'s point about trying out Trac, since it's
> >>already up and running. Josh D., can you just turn that on? (BTW, is
> >>trac linked off http://commandprompt.com anywhere? I had to google to
> >>find it yesterday...)
> >
> >I just noticed that the code repository on that Trac is broken in more
> >ways than I had realized. For starters it doesn't seem to have the 8.1
> >branch or tags (apparently it's out of date).
>
> It doesn't?
>
> http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql
>
> What are you looking at Alvaro?

Exactly that URL, but this wasn't there when I looked. Maybe it was
being regenerated at that time?

But I don't know why you are ignoring my comments that it's broken. For
an example, go here:

http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src

Note that the DEVELOPERS file shows a revision 5684, message "Typo fix".
Click on that 5684. It'll show you two items, revs 23689 and 5684.
First problem, where did that 23689 come from? It wasn't there in the
parent dir. Now open that changeset (click on the [23689]). Look at
the list of files -- it only has errcodes.sgml in it. No DEVELOPERS,
which is the file we want to track! Furthermore, it doesn't show any
diff at all.

I have looked at it before and I've found these kinds of problems all
over the place.

If you mark "follow copies" in the box at the right and then click
Update, more broken revisions will appear. It's impossible to actually
follow the history of a file, because all the entries are bogus.

I don't know what on earth is going on but I surely won't waste my time
checking that repo again since it seems pretty useless.

> >Doesn't Trac have a CVS plugin?
>
> No, like the rest of the world, Trac has moved on from CVS ;)

There are still a lot of projects using CVS. We happen to be one of
them.

It's pretty damn useful to be able to use the Trac facilities to mark
tickets as "fixed in revision such-and-such", which allows us to track
more carefully the bugs fixed and the features added. But if the repo
is useless, then the rest of Trac loses a lot of its usefulness as well.

> And to be clear, I would only expect that this would be used as a
> reference, that is all. The ability to link from the wiki directly to a
> source file or changeset could be useful.

Precisely my point. But if the reference doesn't work, then it's just a
plain Wiki like any other. I wouldn't want to waste my time on that.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

>> http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql
>>
>> What are you looking at Alvaro?
>
> Exactly that URL, but this wasn't there when I looked. Maybe it was
> being regenerated at that time?
>

Yeah it gets regenerated every 4 hours or so.

> But I don't know why you are ignoring my comments that it's broken. For
> an example, go here:
>
> http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src

No one is ignoring you.

>
> Note that the DEVELOPERS file shows a revision 5684, message "Typo fix".
> Click on that 5684. It'll show you two items, revs 23689 and 5684.
> First problem, where did that 23689 come from? It wasn't there in the
> parent dir. Now open that changeset (click on the [23689]). Look at
> the list of files -- it only has errcodes.sgml in it. No DEVELOPERS,
> which is the file we want to track! Furthermore, it doesn't show any
> diff at all.

O.k. So it isn't perfect. It isn't like I expected to be. However many
people find it useful, myself included.

> I don't know what on earth is going on but I surely won't waste my time
> checking that repo again since it seems pretty useless.

O.k., I am not sure who put oil in your pudding, but nobody is asking
you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually
what *you* should be using.

I would expect that if the SVN/Trac repo were determined to be used it
would be used as an entry point and that explicit instructions would
also be made that the authoritative source of the code is the CVSWeb
repository.

>>> Doesn't Trac have a CVS plugin?
>> No, like the rest of the world, Trac has moved on from CVS ;)
>
> There are still a lot of projects using CVS. We happen to be one of
> them.

Unfortunately that is true.

> It's pretty damn useful to be able to use the Trac facilities to mark
> tickets as "fixed in revision such-and-such", which allows us to track
> more carefully the bugs fixed and the features added. But if the repo
> is useless, then the rest of Trac loses a lot of its usefulness as well.

O.k. but no one is suggesting that we use Trac as a bug tracker, or at
least I wasn't. All I was suggesting was the ability to help viewing of
specific files as listed dependencies.

> Precisely my point. But if the reference doesn't work, then it's just a
> plain Wiki like any other. I wouldn't want to waste my time on that.
>

I just threw the trac out there because it was already setup. I don't
care if anyone uses it or not. Nor am I suggesting that it *should* be used.

Lastly if you review this thread you would see that Andrew and I had
already decided to wait until after Linux World to actually propose
something.

It may be Trac it may be something else. For example, I am also looking
at Launchpad. There is also something very similar to trac that is built
on ruby on rails that also integrates with mailing lists.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

>
> I do not agree. How you determine what release fixes the bug now? We
> have web page and mailing list for bug reporting but there is not any
> relation between bug, patch and release(s). I think bug tracking is
> necessary if we want move forward.

You can completely forget the idea of having an actual bug tracking
system. It has been beaten to death over the years. The developers have
very specific requirements that no bug tracker currently adheres to.

If you are in the mood for a long, never ending soap opera on the topic
I suggest you review the archives :)

Sincerely,

Joshua D. Drake

>
> Zdenek
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Joshua D. Drake wrote:
>
> Lastly if you review this thread you would see that Andrew and I had
> already decided to wait until after Linux World to actually propose
> something.
>
>

It is perhaps not surprising, but most of the discussion has been
focused on technologies (mailing lists, wikis, bugtrackers, trac, SCM
systems, etc.). My view is that these things are at best enablers of
good process, but they should not define the processes used. I am trying
to spend what little time I can devote to this topic to thinking about
the issues I see in human rather than technological terms.

cheers

andrew

Joshua D. Drake wrote:
>
> >>http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql
> >>
> >>What are you looking at Alvaro?
> >
> >Exactly that URL, but this wasn't there when I looked. Maybe it was
> >being regenerated at that time?
>
> Yeah it gets regenerated every 4 hours or so.

Suggestion -- have it create the new copy in a separate directory and
when it's complete, rename the new one to the original name. That way
the update is "atomic" and users don't get to see an incomplete repo.

> >I don't know what on earth is going on but I surely won't waste my time
> >checking that repo again since it seems pretty useless.
>
> O.k., I am not sure who put oil in your pudding, but nobody is asking
> you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually
> what *you* should be using.

Actually I'd *like* to use something better than CVSWeb, because you
know what? It sucks and I'd love to have something better. I'd also
like to have a decent bugtracker as well. If both repo and bugtracker
are integrated it could be very useful. We almost have that with Trac
but since it doesn't work, it's so close as to instill hope but because
of the bugs it's useless so it brings frustration instead, which is
much worse than if it didn't do either.

> >It's pretty damn useful to be able to use the Trac facilities to mark
> >tickets as "fixed in revision such-and-such", which allows us to track
> >more carefully the bugs fixed and the features added. But if the repo
> >is useless, then the rest of Trac loses a lot of its usefulness as well.
>
> O.k. but no one is suggesting that we use Trac as a bug tracker, or at
> least I wasn't. All I was suggesting was the ability to help viewing of
> specific files as listed dependencies.

I am suggesting that. I have heard all the old discussions about not
using a bugtracker, but in all fairness, I think some of us have to
create critical mass and get something started. Those who don't want to
use it can choose not to use it, or they can eventually find that yeah,
maybe it's a good idea after all. If no one does anything, nothing will
happen.

I think the devel version of Trac contains some stuff to be able to
handle multiple SCMs. I know there's a Monotone plugin for it at least.
Maybe somebody has already written a CVS plugin as well -- I'll have a
look.

> It may be Trac it may be something else. For example, I am also looking
> at Launchpad. There is also something very similar to trac that is built
> on ruby on rails that also integrates with mailing lists.

Launchpad is proprietary. I don't know about the RoR tool you mention,
it may be worth having a look at.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> > O.k. but no one is suggesting that we use Trac as a bug tracker, or at
> > least I wasn't. All I was suggesting was the ability to help viewing of
> > specific files as listed dependencies.
>
> I am suggesting that. I have heard all the old discussions about not
> using a bugtracker, but in all fairness, I think some of us have to
> create critical mass and get something started. Those who don't want to
> use it can choose not to use it, or they can eventually find that yeah,
> maybe it's a good idea after all. If no one does anything, nothing will
> happen.

Agreed. Seems enough people are interested that even if I don't think
it will work, it is worth a try.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

> Actually I'd *like* to use something better than CVSWeb, because you
> know what? It sucks and I'd love to have something better. I'd also

I am not opposed to actually using taylor or something to do the
conversion instead. I just couldn't get it to work.

> I think the devel version of Trac contains some stuff to be able to
> handle multiple SCMs. I know there's a Monotone plugin for it at least.
> Maybe somebody has already written a CVS plugin as well -- I'll have a
> look.

Well that would make life ALOT easier.

> Launchpad is proprietary. I don't know about the RoR tool you mention,
> it may be worth having a look at.

Launchpad is supposedly releasing their source 10/2006 I believe.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote:
> I just threw the trac out there because it was already setup. I don't
> care if anyone uses it or not. Nor am I suggesting that it *should* be used.
>
> Lastly if you review this thread you would see that Andrew and I had
> already decided to wait until after Linux World to actually propose
> something.
>
> It may be Trac it may be something else. For example, I am also looking
> at Launchpad. There is also something very similar to trac that is built
> on ruby on rails that also integrates with mailing lists.

Does that "rails thing" also have a bug tracker that integrates with
mailing lists? IIRC the show-stopper on a bug tracker was finding one
that allowed people to still use mailing lists.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

Jim C. Nasby wrote:
> On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote:
> > I just threw the trac out there because it was already setup. I don't
> > care if anyone uses it or not. Nor am I suggesting that it *should* be used.
> >
> > Lastly if you review this thread you would see that Andrew and I had
> > already decided to wait until after Linux World to actually propose
> > something.
> >
> > It may be Trac it may be something else. For example, I am also looking
> > at Launchpad. There is also something very similar to trac that is built
> > on ruby on rails that also integrates with mailing lists.
>
> Does that "rails thing" also have a bug tracker that integrates with
> mailing lists? IIRC the show-stopper on a bug tracker was finding one
> that allowed people to still use mailing lists.

AFAIU the showstopper was that people wanted to be able to _control_ the
bugtracker using email only, i.e. not forcing you to open a web browser
to do stuff like adding comments or attachments to a bug, or closing,
etc.

I'm not sure what you have in mind about "integration" between the
mailing lists and the bugtracker, because nothing else I can think of
makes much sense. I'm always happy to be illuminated :-)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Fri, Aug 11, 2006 at 05:27:46PM -0400, Alvaro Herrera wrote:
> > Does that "rails thing" also have a bug tracker that integrates with
> > mailing lists? IIRC the show-stopper on a bug tracker was finding one
> > that allowed people to still use mailing lists.
>
> AFAIU the showstopper was that people wanted to be able to _control_ the
> bugtracker using email only, i.e. not forcing you to open a web browser
> to do stuff like adding comments or attachments to a bug, or closing,
> etc.

The only bugtracker I know that allows that is debbugs, which a nice
system IMHO, but I'm sure people have differing opinions about that...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

On Fri, 11 Aug 2006, Alvaro Herrera wrote:

> I am suggesting that. I have heard all the old discussions about not
> using a bugtracker, but in all fairness, I think some of us have to
> create critical mass and get something started.

I will install anything, and everything, if you can get some sort of
concensus on which one to try / go with ... so far, all discussions have
ended with nobody coming close to agreeing to anything :)

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

RT is easy to setup/configure/use and works well with PostgreSQL
as the backend. CPAN uses it for their bug tracker. Was there a
list of features and requirements?

Ken

On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote:
> On Fri, 11 Aug 2006, Alvaro Herrera wrote:
>
> >I am suggesting that. I have heard all the old discussions about not
> >using a bugtracker, but in all fairness, I think some of us have to
> >create critical mass and get something started.
>
> I will install anything, and everything, if you can get some sort of
> concensus on which one to try / go with ... so far, all discussions have
> ended with nobody coming close to agreeing to anything :)
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
> Yahoo . yscrappy Skype: hub.org ICQ . 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

Marc G. Fournier wrote:

> On Fri, 11 Aug 2006, Alvaro Herrera wrote:
>
>> I am suggesting that. I have heard all the old discussions about not
>> using a bugtracker, but in all fairness, I think some of us have to
>> create critical mass and get something started.
>
>
> I will install anything, and everything, if you can get some sort of
> concensus on which one to try / go with ... so far, all discussions
> have ended with nobody coming close to agreeing to anything :)
>
> ----
> Marc G. Fournier Hub.Org Networking Services
> (http://www.hub.org)
> Email . scrappy(at)hub(dot)org MSN .
> scrappy(at)hub(dot)org
> Yahoo . yscrappy Skype: hub.org ICQ . 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
quite frankly, I think this group needs the same kind of consensus found
in Torvalds kernel group. Is anyone denying their approach gets better
results!? No flatline there. JMUASFANPWWMR!

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date: 8/14/2006

On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
> RT is easy to setup/configure/use and works well with PostgreSQL
> as the backend. CPAN uses it for their bug tracker. Was there a
> list of features and requirements?

I don't know if we ever came up with one, but I know that the big "deal
killer" for a bug tracker is that a lot of hackers don't want to be
forced to use a web interface instead of email. So basically, to be
accepted, a bug tracker would have to have an effective email interface;
one that allowed for updates to an issue coming in via email. Sadly, I
don't think such an animal exists.

> Ken
>
> On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote:
> > On Fri, 11 Aug 2006, Alvaro Herrera wrote:
> >
> > >I am suggesting that. I have heard all the old discussions about not
> > >using a bugtracker, but in all fairness, I think some of us have to
> > >create critical mass and get something started.
> >
> > I will install anything, and everything, if you can get some sort of
> > concensus on which one to try / go with ... so far, all discussions have
> > ended with nobody coming close to agreeing to anything :)
> >
> > ----
> > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> > Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
> > Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

On Tue, 15 Aug 2006, Jim C. Nasby wrote:

> On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
>> RT is easy to setup/configure/use and works well with PostgreSQL
>> as the backend. CPAN uses it for their bug tracker. Was there a
>> list of features and requirements?
>
> I don't know if we ever came up with one, but I know that the big "deal
> killer" for a bug tracker is that a lot of hackers don't want to be
> forced to use a web interface instead of email. So basically, to be
> accepted, a bug tracker would have to have an effective email interface;
> one that allowed for updates to an issue coming in via email. Sadly, I
> don't think such an animal exists.

GnATs :)

>
>> Ken
>>
>> On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote:
>>> On Fri, 11 Aug 2006, Alvaro Herrera wrote:
>>>
>>>> I am suggesting that. I have heard all the old discussions about not
>>>> using a bugtracker, but in all fairness, I think some of us have to
>>>> create critical mass and get something started.
>>>
>>> I will install anything, and everything, if you can get some sort of
>>> concensus on which one to try / go with ... so far, all discussions have
>>> ended with nobody coming close to agreeing to anything :)
>>>
>>> ----
>>> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
>>> Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
>>> Yahoo . yscrappy Skype: hub.org ICQ . 7615664
>>>
>>> ---------------------------(end of broadcast)---------------------------
>>> TIP 2: Don't 'kill -9' the postmaster
>>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 6: explain analyze is your friend
>>
>
> --
> Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
> Pervasive Software http://pervasive.com work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
>

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

RT has an E-mail interface. That was one of our considerations
when we used it to replace our aging trouble ticket system. What
does the interface need to do? RT's is pretty flexible.

Ken

On Tue, Aug 15, 2006 at 04:59:46PM -0500, Jim C. Nasby wrote:
> On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
> > RT is easy to setup/configure/use and works well with PostgreSQL
> > as the backend. CPAN uses it for their bug tracker. Was there a
> > list of features and requirements?
>
> I don't know if we ever came up with one, but I know that the big "deal
> killer" for a bug tracker is that a lot of hackers don't want to be
> forced to use a web interface instead of email. So basically, to be
> accepted, a bug tracker would have to have an effective email interface;
> one that allowed for updates to an issue coming in via email. Sadly, I
> don't think such an animal exists.
>
> > Ken
> >
> > On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote:
> > > On Fri, 11 Aug 2006, Alvaro Herrera wrote:
> > >
> > > >I am suggesting that. I have heard all the old discussions about not
> > > >using a bugtracker, but in all fairness, I think some of us have to
> > > >create critical mass and get something started.
> > >
> > > I will install anything, and everything, if you can get some sort of
> > > concensus on which one to try / go with ... so far, all discussions have
> > > ended with nobody coming close to agreeing to anything :)
> > >
> > > ----
> > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> > > Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
> > > Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 2: Don't 'kill -9' the postmaster
> > >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> >
>
> --
> Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
> Pervasive Software http://pervasive.com work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
>

Jim C. Nasby wrote:
> On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
> > RT is easy to setup/configure/use and works well with PostgreSQL
> > as the backend. CPAN uses it for their bug tracker. Was there a
> > list of features and requirements?
>
> I don't know if we ever came up with one, but I know that the big "deal
> killer" for a bug tracker is that a lot of hackers don't want to be
> forced to use a web interface instead of email. So basically, to be
> accepted, a bug tracker would have to have an effective email interface;
> one that allowed for updates to an issue coming in via email. Sadly, I
> don't think such an animal exists.

We have three candidates already -- debbugs, RT and Gnats. The first
has the advantage that was written by hackers, for hackers, so it
doesn't have any of the insane "for end users" stuff which annoys so
many people around here ;-) (On the other hand it does have some web
stuff for generating reports, etc).

I haven't used RT much, and I don't know Gnats at all, but I kinda like
(the little I have played with) debbugs. Apparently it's rather easy to
set up:

http://www.benham.net/debbugs/

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

I've used and use RT. It is web based for admin, but all the transactions
are E-Mail based.

http://www.bestpractical.com

I can also make a test queue on my instance if someone wants to play.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler(at)lerctr(dot)org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US

In an attempt to throw the authorities off his trail, ler(at)lerctr(dot)org ("Larry Rosenman") transmitted:
> I've used and use RT. It is web based for admin, but all the transactions
> are E-Mail based.
>
> http://www.bestpractical.com
>
> I can also make a test queue on my instance if someone wants to play.

We've got an RT system at work where some queues are set up to be
"sorta email manageable."

I see in their docs a "CommandByMail" extension that allows doing such
things via email request as:
- changing queue
- setting status, custom fields
- assigning owners, watchers, links

It's not self-evident what the security implications are; I'm not sure
how requests are authenticated.
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://linuxfinances.info/info/finances.html
As of next month, MACLISP "/" will be flushed in favor of "\".
Please update the WORLD.

> We have three candidates already -- debbugs, RT and Gnats. The first
> has the advantage that was written by hackers, for hackers, so it
> doesn't have any of the insane "for end users" stuff which annoys so
> many people around here ;-) (On the other hand it does have some web
> stuff for generating reports, etc).

Kill me now if I have to use GNATS :) Have you ever tried submitting a
bug to the FreeBSD project? *shudder*

That said, I'll live :)

I have recently totally falling in love with Trac and its complete
subversion integration. I'm not sure it supports PostgreSQL, and
converting to subversion is probably a little too hardcore at the
moment :)

Chris

Martha Stewart called it a Good Thing when chris(dot)kingslynne(at)gmail(dot)com ("Christopher Kings-Lynne") wrote:
>> We have three candidates already -- debbugs, RT and Gnats. The
>> first has the advantage that was written by hackers, for hackers,
>> so it doesn't have any of the insane "for end users" stuff which
>> annoys so many people around here ;-) (On the other hand it does
>> have some web stuff for generating reports, etc).
>
> Kill me now if I have to use GNATS :) Have you ever tried submitting
> a bug to the FreeBSD project? *shudder*
>
> That said, I'll live :)
>
> I have recently totally falling in love with Trac and its complete
> subversion integration. I'm not sure it supports PostgreSQL, and
> converting to subversion is probably a little too hardcore at the
> moment :)

Trac does support PostgreSQL...

The thing I don't understand at this point is what exactly is the
nature of the integration with the SCM.

I don't see it being likely that there will be a deep integration of
the PostgreSQL SCM (whatever the SCM platform) with Trac; that's way
too much change to expect quickly...
--
(reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc"))
http://linuxdatabases.info/info/spreadsheets.html
Any programmer who fails to comply with the standard naming,
formatting, or commenting conventions should be shot. If it so
happens that it is inconvenient to shoot him, then he is to be
politely requested to recode his program in adherence to the above
standard. -- Michael Spier, Digital Equipment Corporation

Christopher Kings-Lynne wrote:

>> We have three candidates already -- debbugs, RT and Gnats. The first
>> has the advantage that was written by hackers, for hackers, so it
>> doesn't have any of the insane "for end users" stuff which annoys so
>> many people around here ;-) (On the other hand it does have some web
>> stuff for generating reports, etc).
>
>
> Kill me now if I have to use GNATS :) Have you ever tried submitting a
> bug to the FreeBSD project? *shudder*
>
> That said, I'll live :)
>
> I have recently totally falling in love with Trac and its complete
> subversion integration. I'm not sure it supports PostgreSQL, and
> converting to subversion is probably a little too hardcore at the
> moment :)
>
> Chris
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
CVS users just rot away or are subverted.

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006

> Trac does support PostgreSQL...
>
> The thing I don't understand at this point is what exactly is the
> nature of the integration with the SCM.
>
> I don't see it being likely that there will be a deep integration of
> the PostgreSQL SCM (whatever the SCM platform) with Trac; that's way
> too much change to expect quickly...

Basically I have it set up like this:

* Trac has built-in browsing of the svn via the web

* When I commit, the commit message must have a reference to an open
ticket in Trac, eg:

"Rearrange blah to fix bad bug. Fixes #745"

* In trac's "development timeline", or whatever you can see all the
commits against each ticket, and just click on them to see the
complete diff for each change set in SVN.

* Commit messages can contain full wiki markup, that fully integrates
with the wiki that is all thoughout Trac. So, you can have wiki in
your commit messages that refers to other bugs, wiki pages, source
code files and lines, etc.

Basically, Trac is cool. I don't see us adopting it too quickly for
PostgreSQL though :P

Chris

"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> I don't know if we ever came up with one, but I know that the big "deal
> killer" for a bug tracker is that a lot of hackers don't want to be
> forced to use a web interface instead of email. So basically, to be
> accepted, a bug tracker would have to have an effective email interface;
> one that allowed for updates to an issue coming in via email. Sadly, I
> don't think such an animal exists.

That was the position that several of us took five-or-six years ago when
the issue first came up ;-)

These days I doubt there's anyone around the project who refuses to use
a web browser at all. However, I still personally find it much more
convenient to read and respond to mailing-list postings than to have to
go and visit random web pages to find out if there's something I need to
know about. So my current take on this would be that the bug tracker
would have to have a reasonable "output" email capability, but I'd not
necessarily insist on being able to "input" to it by mail. Red Hat's
present bugzilla system could be described that way --- and while I
can't say I'm in love with it, I can deal with it.

Now the other side of the coin is that people are used to being able to
email problem reports to pgsql-bugs, and that's not going to stop
anytime soon. If you don't mind having a bug tracker that is clueless
about some fair-size fraction of what is going on, then you can set up a
system that is impervious to email input. Just don't expect people to
trust it very far.

regards, tom lane

On Aug 16, 2006, at 12:29 , Tom Lane wrote:

> So my current take on this would be that the bug tracker
> would have to have a reasonable "output" email capability, but I'd not
> necessarily insist on being able to "input" to it by mail.

Setting aside the email in, how would people feel about Atom or RSS
feeds as an alternative for alerts of activity in the system?

Michael Glaesemann
grzm seespotcode net

Tom Lane wrote:
> that the bug tracker would have to have a reasonable "output" email
> capability, but I'd not necessarily insist on being able to "input"
> to it by mail. Red Hat's present bugzilla system could be described
> that way --- and while I can't say I'm in love with it, I can deal
> with it.

Bugzilla is good in that you need to sign up to report anything (or at
least it can be configured that way, not sure), which might reduce the
amount of noise. The other systems that have been mentioned have by
design little or no barrier of entry, which doesn't seem to be what we
want.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Tom,

> These days I doubt there's anyone around the project who refuses to use
> a web browser at all. However, I still personally find it much more
> convenient to read and respond to mailing-list postings than to have to
> go and visit random web pages to find out if there's something I need to
> know about. So my current take on this would be that the bug tracker
> would have to have a reasonable "output" email capability, but I'd not
> necessarily insist on being able to "input" to it by mail. Red Hat's
> present bugzilla system could be described that way --- and while I
> can't say I'm in love with it, I can deal with it.

Actually, if that's the only objection it's solved. RT will now allow you to
create, comment on, modify, and close bugs by e-mail. And the RT team would
be thrilled to have us using it, in theory enough to provide some setup help.
There's one thing that RT doesn't do by e-mail (can't remember offhand) but
that's a TODO for them so it should be fixed soon.

So, if the only real requirement for a bug tracker is that we can handle it
100% by e-mail, and integrate it with the pgsql-bugs list, that is possible.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

On Wednesday 16 August 2006 00:52, Peter Eisentraut wrote:
> Tom Lane wrote:
> > that the bug tracker would have to have a reasonable "output" email
> > capability, but I'd not necessarily insist on being able to "input"
> > to it by mail. Red Hat's present bugzilla system could be described
> > that way --- and while I can't say I'm in love with it, I can deal
> > with it.
>
> Bugzilla is good in that you need to sign up to report anything (or at
> least it can be configured that way, not sure), which might reduce the
> amount of noise. The other systems that have been mentioned have by
> design little or no barrier of entry, which doesn't seem to be what we
> want.

I'm not sure I follow this, since currently anyone can email the bugs list or
use the bugs -> email form from the website. Are you looking to increase the
barrier for bug reporting?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
> I'm not sure I follow this, since currently anyone can email the bugs list
> or use the bugs -> email form from the website. Are you looking to
> increase the barrier for bug reporting?

Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most
are confused or misdirected users. I don't want to raise that barrier. But
I want a higher barrier before something is recorded in the bug tracking
system.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote:
> Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
> > I'm not sure I follow this, since currently anyone can email the bugs list
> > or use the bugs -> email form from the website. Are you looking to
> > increase the barrier for bug reporting?
>
> Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most
> are confused or misdirected users. I don't want to raise that barrier. But
> I want a higher barrier before something is recorded in the bug tracking
> system.

Well, you need to get some agreement on what the bug tracker is for. Is
it:

a) a front-end to deal with complaints and bugs people have. Is it
something you expect end users to look at? This is how Debian uses its
bug-tracker, to make sure issues people bring up don't get lost. You
can always close the bug if it isn't a real bug.

Or:

b) a private bug database only used by -hackers to track known
outstanding bugs and patches.

If you want the latter, the approach would be to keep pgsql-bugs and
when a real issue comes up, bounce it to the bug tracker. Any
subsequent email discussion should then get logged in the bug report.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

On Wed, Aug 16, 2006 at 06:52:21AM +0200, Peter Eisentraut wrote:
> Tom Lane wrote:
> > that the bug tracker would have to have a reasonable "output" email
> > capability, but I'd not necessarily insist on being able to "input"
> > to it by mail. Red Hat's present bugzilla system could be described
> > that way --- and while I can't say I'm in love with it, I can deal
> > with it.
>
> Bugzilla is good in that you need to sign up to report anything (or at
> least it can be configured that way, not sure), which might reduce the
> amount of noise. The other systems that have been mentioned have by
> design little or no barrier of entry, which doesn't seem to be what we
> want.
>
We put an anti-spam solution w/quarantine in front of our RT E-mail
instance (DSPAM) and it is very effective at keeping the cruft out of
the tracking system. You can also do basic processing on incoming
messages to weed out the "non-bugs". We put them in a General start
queue and then move them to other working queues when they meet
whatever threshold you set. The General queue could also automatically
timeout/close tickets that stay in the queue for a certain period of
time.

Ken

On Wed, Aug 16, 2006 at 01:22:43PM +0900, Michael Glaesemann wrote:
>
> On Aug 16, 2006, at 12:29 , Tom Lane wrote:
>
> >So my current take on this would be that the bug tracker
> >would have to have a reasonable "output" email capability, but I'd not
> >necessarily insist on being able to "input" to it by mail.
>
> Setting aside the email in, how would people feel about Atom or RSS
> feeds as an alternative for alerts of activity in the system?
>
> Michael Glaesemann
> grzm seespotcode net
>
>
RT has an RSS output. A particular set of criteria can be used to
populate it on an individual basis.

Ken

Martijn van Oosterhout wrote:
> On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote:
>
>> Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
>>
>>> I'm not sure I follow this, since currently anyone can email the bugs list
>>> or use the bugs -> email form from the website. Are you looking to
>>> increase the barrier for bug reporting?
>>>
>> Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most
>> are confused or misdirected users. I don't want to raise that barrier. But
>> I want a higher barrier before something is recorded in the bug tracking
>> system.
>>
>
> Well, you need to get some agreement on what the bug tracker is for. Is
> it:
>
> a) a front-end to deal with complaints and bugs people have. Is it
> something you expect end users to look at? This is how Debian uses its
> bug-tracker, to make sure issues people bring up don't get lost. You
> can always close the bug if it isn't a real bug.
>
> Or:
>
> b) a private bug database only used by -hackers to track known
> outstanding bugs and patches.
>
> If you want the latter, the approach would be to keep pgsql-bugs and
> when a real issue comes up, bounce it to the bug tracker. Any
> subsequent email discussion should then get logged in the bug report.
>
> Have a nice day,
>

What we are talking about here is bug triage. Weeding out misreports,
duplicates etc. is a prime part of this function. It is essential to the
health of any functioning bug tracking system. All it takes is
resources. Is it worth it? Yes, IMNSHO, but it's a judgement call.

One sensible way to do this would be to have a group of suitably
qualified volunteers who could perform this function on a roster basis,
for, say, a week or a two at a time. That way we could the load off key
personnel like Tom (I am in favor of anything which would reduce the
demands we place on Tom ;-) )

cheers

andrew

Kenneth Marshall wrote:
> RT is easy to setup/configure/use and works well with PostgreSQL
> as the backend.

RT works with Postgres, but I wouldn't say well. All queries in RT are
generated by a query generator due to a naive obsession with database
independance. They've achieved database independance at the cost of all
the queries being brain-dead. Fixing the query generator would be a
pretty big job.

Drew

On Wed, Aug 16, 2006 at 11:12:11AM +0800, Christopher Kings-Lynne wrote:
> >Trac does support PostgreSQL...
> >
> >The thing I don't understand at this point is what exactly is the
> >nature of the integration with the SCM.
> >
> >I don't see it being likely that there will be a deep integration of
> >the PostgreSQL SCM (whatever the SCM platform) with Trac; that's way
> >too much change to expect quickly...
>
> Basically I have it set up like this:
>
> * Trac has built-in browsing of the svn via the web
>
> * When I commit, the commit message must have a reference to an open
> ticket in Trac, eg:
>
> "Rearrange blah to fix bad bug. Fixes #745"
>
> * In trac's "development timeline", or whatever you can see all the
> commits against each ticket, and just click on them to see the
> complete diff for each change set in SVN.
>
> * Commit messages can contain full wiki markup, that fully integrates
> with the wiki that is all thoughout Trac. So, you can have wiki in
> your commit messages that refers to other bugs, wiki pages, source
> code files and lines, etc.
>
> Basically, Trac is cool. I don't see us adopting it too quickly for
> PostgreSQL though :P

Well, CMD does have it up and running with our repository as sucked out
of CVS. Granted, not full functionality, but better than nothing. If
Josh turns on the rest of the stuff folks could go play with it and see
what they think.

BTW, if GNATS is what FreeBSD uses I'd have to agree that it's pretty
ugly.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

On Wed, Aug 16, 2006 at 09:14:47AM -0400, Andrew Dunstan wrote:
> What we are talking about here is bug triage. Weeding out misreports,
> duplicates etc. is a prime part of this function. It is essential to the
> health of any functioning bug tracking system. All it takes is
> resources. Is it worth it? Yes, IMNSHO, but it's a judgement call.
>
> One sensible way to do this would be to have a group of suitably
> qualified volunteers who could perform this function on a roster basis,
> for, say, a week or a two at a time. That way we could the load off key
> personnel like Tom (I am in favor of anything which would reduce the
> demands we place on Tom ;-) )

Actually, I'd bet we don't need to put such a formal system in place. I
suspect that we'll have users actually looking at the incomming bugs and
commenting if they're not valid. As we notice folks who are doing a good
job of that, we can give them the privleges to mark bugs as invalid.

In the meantime, I'd be glad to help out with 'weeding' incomming bug
reports. Depending on the bug tracking system, you can even just let
people do this ad-hoc... bugzilla (for example) has an unconfirmed
status for new bugs; it would just take people looking at all
unconfirmed bugs and marking them appropriately.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote:
> Tom,
>
> > These days I doubt there's anyone around the project who refuses to use
> > a web browser at all. However, I still personally find it much more
> > convenient to read and respond to mailing-list postings than to have to
> > go and visit random web pages to find out if there's something I need to
> > know about. So my current take on this would be that the bug tracker
> > would have to have a reasonable "output" email capability, but I'd not
> > necessarily insist on being able to "input" to it by mail. Red Hat's
> > present bugzilla system could be described that way --- and while I
> > can't say I'm in love with it, I can deal with it.
>
> Actually, if that's the only objection it's solved. RT will now allow you to
> create, comment on, modify, and close bugs by e-mail. And the RT team would
> be thrilled to have us using it, in theory enough to provide some setup help.
> There's one thing that RT doesn't do by e-mail (can't remember offhand) but
> that's a TODO for them so it should be fixed soon.
>
> So, if the only real requirement for a bug tracker is that we can handle it
> 100% by e-mail, and integrate it with the pgsql-bugs list, that is possible.

Does Trac have similar capability? Reason I'm asking is that I think
*eventually* it would be very useful to have trac's ability to link
bugs, version control, wiki, etc. all together. I know it'll probably be
quite some time before that happens, but I'm sure that if we go with RT
it'll never happen.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

peter_e(at)gmx(dot)net (Peter Eisentraut) writes:
> Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
>> I'm not sure I follow this, since currently anyone can email the bugs list
>> or use the bugs -> email form from the website. Are you looking to
>> increase the barrier for bug reporting?
>
> Only a small fraction of the new posts on pgsql-bugs are actually
> bugs. Most are confused or misdirected users. I don't want to
> raise that barrier. But I want a higher barrier before something is
> recorded in the bug tracking system.

Seems to me that for there to be a *bit* of a barrier might not be a
bad thing...

If "purported bugs" had to be acknowledged before going into the bug
tracker system, that wouldn't seem a bad thing.

That would mean that the frequent "I don't understand what I'm doing
and didn't read the documentation" reports could be quickly triaged
away, which strikes me as an important prerequisite for further
automating things.
--
select 'cbbrowne' || '@' || 'ntlug.org';
http://cbbrowne.com/info/sap.html
FLORIDA: Relax, Retire, Re Vote.

Jim C. Nasby wrote:

>On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote:
>
>
>>Tom,
>>
>>
>>
>>>These days I doubt there's anyone around the project who refuses to use
>>>a web browser at all. However, I still personally find it much more
>>>convenient to read and respond to mailing-list postings than to have to
>>>go and visit random web pages to find out if there's something I need to
>>>know about. So my current take on this would be that the bug tracker
>>>would have to have a reasonable "output" email capability, but I'd not
>>>necessarily insist on being able to "input" to it by mail. Red Hat's
>>>present bugzilla system could be described that way --- and while I
>>>can't say I'm in love with it, I can deal with it.
>>>
>>>
>>Actually, if that's the only objection it's solved. RT will now allow you to
>>create, comment on, modify, and close bugs by e-mail. And the RT team would
>>be thrilled to have us using it, in theory enough to provide some setup help.
>>There's one thing that RT doesn't do by e-mail (can't remember offhand) but
>>that's a TODO for them so it should be fixed soon.
>>
>>So, if the only real requirement for a bug tracker is that we can handle it
>>100% by e-mail, and integrate it with the pgsql-bugs list, that is possible.
>>
>>
>
>Does Trac have similar capability? Reason I'm asking is that I think
>*eventually* it would be very useful to have trac's ability to link
>bugs, version control, wiki, etc. all together. I know it'll probably be
>quite some time before that happens, but I'm sure that if we go with RT
>it'll never happen.
>
>
guys, just a sobering refrain from the troll audience -- establishing
trac/subversion, as a formal mechanism within postgesql circles, would
go a long way toward showing the real world out there that postgresql is
professionalizing (I know) and systematizing, etc.ad infinitum. Let
everyone identify bugs (keeps novices busy), the more the merrier! New
classes of semi-programmers will arise, lets call them buggers, and
bugger watchers, unless they know English very well, pretty soon, the
system will get used by real programmers, because in the long run, it
saves time, and gets results. And folks, lets learn from the goofs of
the Freebsd crowd, and maybe even from the Torvalds gang. Michael

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006

On Wed, 16 Aug 2006, Robert Treat wrote:

> I'm not sure I follow this, since currently anyone can email the bugs
> list or use the bugs -> email form from the website. Are you looking to
> increase the barrier for bug reporting?

Any garbage (ie. spam) is generally filtered before it hits the -bugs list
itself

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:

> What we are talking about here is bug triage.

Really? We have a problem with too many bug reports and need a tool to help
triage them? That's the first I've heard of that.

Think about what tasks you do now and what tool would make it easier. Don't
try to invent problems to solve.

The Debian system would be basically zero operational change. pgsql-bugs would
continue to exist exactly as it does now except it would go through debbugs.
Any message there would open a bug report. Anyone responding to say "that's
not a bug" would just include the magic phrase to close the bug report too.

Anyone responding with questions or data would just respond as normal. The net
result would be exactly as it is now except that there would be a tool to view
what bugs are still open and look at all the data accumulated on that bug. And
you could look back at old bugs to see what version they were fixed in and
what the bug looked like to see if it matched the problem a user is having.

In short, it's just a tool to solve a problem we actually have (having a
convenient archive of data about current and past bugs) without inventing
problems to solve with extra process that we aren't already doing anyways.

RT can be set up similarly but I'm not sure how much work it would take to
make it as seamless. Debbugs has the advantage of working that way pretty much
out of the box.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark wrote:
> The Debian system would be basically zero operational change.
> pgsql-bugs would continue to exist exactly as it does now except it
> would go through debbugs.

Debbugs is fine and all, but they don't seem to publish their code on a
regular basis.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Andrew Dunstan wrote:
> What we are talking about here is bug triage.

I think we are actually talking about bug *tracking*.

> One sensible way to do this would be to have a group of suitably
> qualified volunteers who could perform this function on a roster
> basis, for, say, a week or a two at a time.

Organising a roster, a rotating roster at that, is probably the single
most difficult thing you can do in this group. :-)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Martijn van Oosterhout wrote:
> If you want the latter, the approach would be to keep pgsql-bugs and
> when a real issue comes up, bounce it to the bug tracker. Any
> subsequent email discussion should then get logged in the bug report.

That's what I want. I don't want the bug tracking system to be the
primary frontend to users off the street. Because quite frankly most
users are too confused to know what a real bug is. That doesn't mean
that I want a closed BTS, but a system that requires sign up and user
accounts (like Bugzilla) imposes the right barrier to random abuse in
my mind.

Note that RT stands for "Request Tracker", which on its face is a
different thing, namely a system to do tracking of requests by users
off the street.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Let me add that most entries that illict a quick patch or TODO item do
not come in through the bugs list, but are rather problems people post
to ther lists, or are the result of discussions.

---------------------------------------------------------------------------

Gregory Stark wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
> > What we are talking about here is bug triage.
>
> Really? We have a problem with too many bug reports and need a tool to help
> triage them? That's the first I've heard of that.
>
> Think about what tasks you do now and what tool would make it easier. Don't
> try to invent problems to solve.
>
> The Debian system would be basically zero operational change. pgsql-bugs would
> continue to exist exactly as it does now except it would go through debbugs.
> Any message there would open a bug report. Anyone responding to say "that's
> not a bug" would just include the magic phrase to close the bug report too.
>
> Anyone responding with questions or data would just respond as normal. The net
> result would be exactly as it is now except that there would be a tool to view
> what bugs are still open and look at all the data accumulated on that bug. And
> you could look back at old bugs to see what version they were fixed in and
> what the bug looked like to see if it matched the problem a user is having.
>
> In short, it's just a tool to solve a problem we actually have (having a
> convenient archive of data about current and past bugs) without inventing
> problems to solve with extra process that we aren't already doing anyways.
>
> RT can be set up similarly but I'm not sure how much work it would take to
> make it as seamless. Debbugs has the advantage of working that way pretty much
> out of the box.
>
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Greg,

> In short, it's just a tool to solve a problem we actually have (having a
> convenient archive of data about current and past bugs) without inventing
> problems to solve with extra process that we aren't already doing anyways.
>
> RT can be set up similarly but I'm not sure how much work it would take to
> make it as seamless. Debbugs has the advantage of working that way pretty much
> out of the box.

Debbugs would be good too. I'll quiz the Debian folks here at the
conference about what issues there are with the system.

FWIW, MySQL is pretty proud of their bug tracker, and Marten offered to
open source it for us. ;-)

--Josh Berkus

Josh Berkus schrieb:
> Greg,
>
>> In short, it's just a tool to solve a problem we actually have (having a
>> convenient archive of data about current and past bugs) without inventing
>> problems to solve with extra process that we aren't already doing
>> anyways.
>>
>> RT can be set up similarly but I'm not sure how much work it would
>> take to
>> make it as seamless. Debbugs has the advantage of working that way
>> pretty much
>> out of the box.
>
> Debbugs would be good too. I'll quiz the Debian folks here at the
> conference about what issues there are with the system.
>
> FWIW, MySQL is pretty proud of their bug tracker, and Marten offered to
> open source it for us. ;-)

What is wrong with for example trac? (trac.edgewall.com) which actually
runs on postgres just fine...

Regards
Tino

> Well, you need to get some agreement on what the bug tracker
> is for. Is
> it:
>
> a) a front-end to deal with complaints and bugs people have.
> Is it something you expect end users to look at? This is how
> Debian uses its bug-tracker, to make sure issues people bring
> up don't get lost. You can always close the bug if it isn't a
> real bug.

If we ask to take all complains, questions and bugs through a
"bugtracker", then it's not a bugtracker. It's more of an "anything goes
tracker", that usually ends up being a web based forum (with mail links)
without all the features that makes a web based forum at all usable.
(And I still think mailinglists are a lot more usable then a web based
forum that *does* have a lot of functionality) This is what IMHO you see
with a *lot* of OSS projects that use bugzilla or whatever. A bazillion
bugs that aren't bugs but discussions or questions etc. Can't speak
about the debian example, haven't checked theirs out.

We already have our mailinglist archives dealing with this. I really
can't see why we'd want to duplicate that and archive things in one more
place.

> Or:
>
> b) a private bug database only used by -hackers to track
> known outstanding bugs and patches.

This, however, I would find very useful - both as a -hacker and as a
user. The point is that only confirmed things should be in there, so
only confirmed things should be returned on searches and whatevr.
(private not as in not visible to the public, but private as in
write-controlled)

As a user/admin/whatever, just listing all bugs affecting an
installation ("8.0 branch after 8.0.4" for example) so I can evaluate if
I need to upgrade is a *very good* thing to be able to do. I realise
this adds a bit of overhead for the people doing commits, but it should
be possible to integrate that to a point where the overhead is
minimized. And it would be a big win.

As a -hacker, not needing to keep my own "mailbox format" or "textfile
format" bugtracker, and being able to easily find something that would
list all communications about a certain bug (*with* links to the
archives, where the actual information would still be) would definitly
be a win.
Tom seems to be able to remember everything in his head and whip out the
old commit messages in no time, but I certainly can't ;-)

> If you want the latter, the approach would be to keep
> pgsql-bugs and when a real issue comes up, bounce it to the
> bug tracker. Any subsequent email discussion should then get
> logged in the bug report.

IMHO, that's the best solution. Except the email discussion lives just
fine in the archives, and should be linked back into the tracker if
possible instead of copied there.

There's also the possibility of
c)
just using a "bugtracker style interface" as a presentation method over
whatever we have now. All our mails go into the archives. If we make
sure that all mails about a certain bug are flagged with that bug id
(easy enough if it's submitted through the bugs form, I'm sure there can
be some voodoo done in majordomo to have it send actual posts to the
lists through a script that would do a similar thing), then a tool could
fairly easy crawl the archives and pick up all emails related to that
bug, and present them separatly. Then if we can convince the committers
to always include the bug id when a commit is done for a bug, we'd have
the commit messages in the tracker as well... You'd still need someone
to fill out metadata like "versions affected" if we want that, but the
effort on the "main developers" would pretty much just be to remember to
keep the bug id around.

//Magnus

> > I'm not sure I follow this, since currently anyone can
> email the bugs
> > list or use the bugs -> email form from the website. Are
> you looking
> > to increase the barrier for bug reporting?
>
> Any garbage (ie. spam) is generally filtered before it hits
> the -bugs list itself

Spam: Yes.
Non-bug-reports: Absolutely not.

The majority of things on -bugs are *not* bug reports, from what I can
tell...

//Magnus

On Thu, Aug 17, 2006 at 06:48:54PM +0200, Magnus Hagander wrote:
> This, however, I would find very useful - both as a -hacker and as a
> user. The point is that only confirmed things should be in there, so
> only confirmed things should be returned on searches and whatevr.
> (private not as in not visible to the public, but private as in
> write-controlled)

I've yet to see a bug tracker that doesn't make it trivial to identify
bugs that were marked as invalid (ie: not a real bug). The only
difference is that you actually have to mark them as such. Given the
fairly low volume of non-bugs that come in through the web form, I don't
think marking them will be a big issue (and as I mentioned previously,
it's something that doesn't have to be done by anyone who's a
committer). In fact, having such a system would probably save committers
time, because they could look only at bugs that had been confirmed as
valid by someone else. Right now, every time a non-bug gets filed dozens
of people end up reading the report before they hit delete.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

Magnus Hagander wrote:
> > > I'm not sure I follow this, since currently anyone can
> > email the bugs
> > > list or use the bugs -> email form from the website. Are
> > you looking
> > > to increase the barrier for bug reporting?
> >
> > Any garbage (ie. spam) is generally filtered before it hits
> > the -bugs list itself
>
> Spam: Yes.
> Non-bug-reports: Absolutely not.
>
> The majority of things on -bugs are *not* bug reports, from what I can
> tell...

And many bugs appear on other lists, so again, it isn't just that the
bugs list isn't just bugs, but that bugs appear elsewhere.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

> These days I doubt there's anyone around the project who
> refuses to use a web browser at all. However, I still
> personally find it much more convenient to read and respond
> to mailing-list postings than to have to go and visit random
> web pages to find out if there's something I need to know
> about. So my current take on this would be that the bug
> tracker would have to have a reasonable "output" email
> capability, but I'd not necessarily insist on being able to
> "input" to it by mail. Red Hat's present bugzilla system
> could be described that way --- and while I can't say I'm in
> love with it, I can deal with it.

Doesn't bugzilla insist on sending you the complete bug every time? Or
am I confusing it with the gforge/pgfoundry trackers? If so, then it's a
really bad idea, IMHO, since it sends new copies out all the time...

> Now the other side of the coin is that people are used to
> being able to email problem reports to pgsql-bugs, and that's
> not going to stop anytime soon. If you don't mind having a
> bug tracker that is clueless about some fair-size fraction of
> what is going on, then you can set up a system that is
> impervious to email input. Just don't expect people to trust
> it very far.

Whatever system is used (if one is), there definitly needs to be some
people looking over what comes in on the mailinglists (or on IRC, for
that matter) and pipe it off to the tracker in case it's not already
there. Unless we want to force everybody to use *just* a web interface
(which would be a horrible idea, btw), we won't get 100% coverage.

(btw, istm that people email at least as many bugs directly to -hackers,
or to -general or whatever, because the end user *does not know* when
it's a bug from when it's a misconfiguration, or misunderstanding of the
issue or whatnot)

//Magnus

> > This, however, I would find very useful - both as a -hacker
> and as a
> > user. The point is that only confirmed things should be in
> there, so
> > only confirmed things should be returned on searches and whatevr.
> > (private not as in not visible to the public, but private as in
> > write-controlled)
>
> I've yet to see a bug tracker that doesn't make it trivial to
> identify bugs that were marked as invalid (ie: not a real
> bug). The only difference is that you actually have to mark
> them as such. Given the fairly low volume of non-bugs that
> come in through the web form, I don't think marking them will
> be a big issue (and as I mentioned previously, it's something
> that doesn't have to be done by anyone who's a committer). In
> fact, having such a system would probably save committers
> time, because they could look only at bugs that had been
> confirmed as valid by someone else. Right now, every time a
> non-bug gets filed dozens of people end up reading the report
> before they hit delete.

Well, if it's invalid, it shouldn't be in there. But I guess you could
just go ahead and delete it at that point - but it's work that someone
has to do.

But when I look at a lot of OSS projects out there, I see hundreds (if
not thousands or tens of thousands for large projects) of bugs that are
just dangling. That likely aren't bugs, but they are listed as such.
Could definitly be that it's just that the system isn't maintained
properly, but if so many others have failed, there's definitly a
nontrivial risk that we would fail as well.

//Magnus

On Thu, Aug 17, 2006 at 07:00:21PM +0200, Magnus Hagander wrote:
> > These days I doubt there's anyone around the project who
> > refuses to use a web browser at all. However, I still
> > personally find it much more convenient to read and respond
> > to mailing-list postings than to have to go and visit random
> > web pages to find out if there's something I need to know
> > about. So my current take on this would be that the bug
> > tracker would have to have a reasonable "output" email
> > capability, but I'd not necessarily insist on being able to
> > "input" to it by mail. Red Hat's present bugzilla system
> > could be described that way --- and while I can't say I'm in
> > love with it, I can deal with it.
>
> Doesn't bugzilla insist on sending you the complete bug every time? Or
> am I confusing it with the gforge/pgfoundry trackers? If so, then it's a
> really bad idea, IMHO, since it sends new copies out all the time...

No. In fact, it's one of the few that doesn't do that. I agree that
sending the whole bug is a really dumb idea.

> > Now the other side of the coin is that people are used to
> > being able to email problem reports to pgsql-bugs, and that's
> > not going to stop anytime soon. If you don't mind having a
> > bug tracker that is clueless about some fair-size fraction of
> > what is going on, then you can set up a system that is
> > impervious to email input. Just don't expect people to trust
> > it very far.
>
> Whatever system is used (if one is), there definitly needs to be some
> people looking over what comes in on the mailinglists (or on IRC, for
> that matter) and pipe it off to the tracker in case it's not already
> there. Unless we want to force everybody to use *just* a web interface
> (which would be a horrible idea, btw), we won't get 100% coverage.
>
> (btw, istm that people email at least as many bugs directly to -hackers,
> or to -general or whatever, because the end user *does not know* when
> it's a bug from when it's a misconfiguration, or misunderstanding of the
> issue or whatnot)

Yes, there will have to be cross-checking. However, in practice, I've
found that users will enter the bug themselves if you send them a reply
asking them to, so I don't think it should pose too much additional
burden.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote:
> > I've yet to see a bug tracker that doesn't make it trivial to
> > identify bugs that were marked as invalid (ie: not a real
> > bug). The only difference is that you actually have to mark
> Well, if it's invalid, it shouldn't be in there. But I guess you could
> just go ahead and delete it at that point - but it's work that someone
> has to do.
>
> But when I look at a lot of OSS projects out there, I see hundreds (if
> not thousands or tens of thousands for large projects) of bugs that are
> just dangling. That likely aren't bugs, but they are listed as such.
> Could definitly be that it's just that the system isn't maintained
> properly, but if so many others have failed, there's definitly a
> nontrivial risk that we would fail as well.

I always see people getting bent out-of-shape about bug trackers that
contain a lot of invalid bug reports and I never understand why. Most of
the ones I've seen hide those by default, so it's not like you really
have to deal with them. And having them still exist is useful... for
example, if you keep seeing the same thing come up over and over you
know there's probably an issue of some kind (ie: documentation). Plus,
if users are encouraged to search for the bug they found before
reporting it and *that* search by default includes invalid bugs then
it's more likely that the user will find the question (and answer)
themselves.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>> ... Red Hat's present bugzilla system
>> could be described that way --- and while I can't say I'm in
>> love with it, I can deal with it.

> Doesn't bugzilla insist on sending you the complete bug every time?

Nope, it just sends the changes/additions. Other than the lack of a
direct email input method, I find BZ quite usable. Josh was just
complaining that its source code is a mess (dunno, haven't looked)
but other than that I think it's a definite possibility, just because
so many people are already familiar with it.

> Whatever system is used (if one is), there definitly needs to be some
> people looking over what comes in on the mailinglists (or on IRC, for
> that matter) and pipe it off to the tracker in case it's not already
> there.

Sure; we'd need a few volunteers handling that, no matter what software
we pick.

regards, tom lane

Jim C. Nasby wrote:
> On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote:
>
>>> I've yet to see a bug tracker that doesn't make it trivial to
>>> identify bugs that were marked as invalid (ie: not a real
>>> bug). The only difference is that you actually have to mark
>>>
>> Well, if it's invalid, it shouldn't be in there. But I guess you could
>> just go ahead and delete it at that point - but it's work that someone
>> has to do.
>>
>> But when I look at a lot of OSS projects out there, I see hundreds (if
>> not thousands or tens of thousands for large projects) of bugs that are
>> just dangling. That likely aren't bugs, but they are listed as such.
>> Could definitly be that it's just that the system isn't maintained
>> properly, but if so many others have failed, there's definitly a
>> nontrivial risk that we would fail as well.
>>
>
> I always see people getting bent out-of-shape about bug trackers that
> contain a lot of invalid bug reports and I never understand why. Most of
> the ones I've seen hide those by default, so it's not like you really
> have to deal with them. And having them still exist is useful... for
> example, if you keep seeing the same thing come up over and over you
> know there's probably an issue of some kind (ie: documentation). Plus,
> if users are encouraged to search for the bug they found before
> reporting it and *that* search by default includes invalid bugs then
> it's more likely that the user will find the question (and answer)
> themselves.
>

If the crud isn't handled some way then the system isn't nearly as much
use to you. That's why I believe some sort of process for keeping the
bug tracking system reasonably clean is necessary.

cheers

andrew

Tom Lane wrote:
>> Doesn't bugzilla insist on sending you the complete bug every time?
>>
>
> Nope, it just sends the changes/additions. Other than the lack of a
> direct email input method, I find BZ quite usable. Josh was just
> complaining that its source code is a mess (dunno, haven't looked)
> but other than that I think it's a definite possibility, just because
> so many people are already familiar with it.
>
>
One other point about BZ - several community members (including me) put
in some effort to make the trunk version run on postgres, which it now
does, and quite well. So our using it would be a nice return compliment.
The source code might well be a mess, but for the most part it can just
be treated as a black box.
>> Whatever system is used (if one is), there definitly needs to be some
>> people looking over what comes in on the mailinglists (or on IRC, for
>> that matter) and pipe it off to the tracker in case it's not already
>> there.
>>
>
> Sure; we'd need a few volunteers handling that, no matter what software
> we pick.
>
>
>

You betcha. I'm glad we agree about that.

cheers

andrew

Tom Lane wrote:
> "Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> >> ... Red Hat's present bugzilla system
> >> could be described that way --- and while I can't say I'm in
> >> love with it, I can deal with it.
>
> > Doesn't bugzilla insist on sending you the complete bug every time?
>
> Nope, it just sends the changes/additions. Other than the lack of a
> direct email input method, I find BZ quite usable. Josh was just
> complaining that its source code is a mess (dunno, haven't looked)
> but other than that I think it's a definite possibility, just because
> so many people are already familiar with it.

Have you tried to use debbugs? I agree with Greg Stark that it's a
better fit for our current procedure, while enabling better
traceability.

For an example, see http://bugs.debian.org. There are three links there
pointing to pages on how to use the system. Entering a bug number shows
detail; for example try entering 330514 which is a PostgreSQL bug. You
can add more detail to a bug by mailing <bug-number>@bugs.debian.org.
You can close a bug by mailing <bug-number>-done(at)bugs(dot)debian(dot)org(dot) You
can of course clone bugs, retarget to a different package, merge bugs,
etc.

It's controllable by email -- in fact, I think email is the only
controlling interface. You can get reports using the web frontend. You
can get an mbox via HTTP for a particular bug, which you can later open
with your email client if you like. (And respond to it, etc).

We would have to determine what constitutes a "package" (probably one
for each contrib module, one for each interface, one for the backend,
etc; or we could have separate package for "optimizer", "rewriter",
"transaction system", one for each access method, etc), what "tags"
there are, what "versions", etc.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Have you tried to use debbugs?

If you can find up-to-date source code for debbugs, we might continue
that line of thought.

The searching capabilities in debbugs are, well, non-existent, which is
a real problem in my mind.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Alvaro Herrera wrote:
> > Have you tried to use debbugs?
>
> If you can find up-to-date source code for debbugs, we might continue
> that line of thought.

Josh Berkus said he'd try to talk to the Debian people at LinuxWorld --
let's see if something materializes from there.

> The searching capabilities in debbugs are, well, non-existent, which is
> a real problem in my mind.

Well, we can set up our own indexing, like Oleg and Teodor have done in
http://www.pgsql.ru/

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Have you tried to use debbugs? I agree with Greg Stark that it's a
> better fit for our current procedure, while enabling better
> traceability.

The principal strike against debbugs seems to be that the source code is
not readily available and/or isn't updated regularly. If we could get
current sources we'd probably end up maintaining our own fork ... OTOH,
given all the enthusiasm being expressed in this thread, somebody would
volunteer to do that no?

Other than that not-small problem, I agree that debbugs seems like an
excellent fit to our existing habits.

regards, tom lane

Did you look at http://www.atlassian.com/software/jira/
- can use postgresql as database
- free to open source projects, used by apache, hiberate, OpenSymphony
- bugs may be submitted via email/web
- built-in configurable workflow
- runs as J2EE webapp on a number of OS's
- lots of other features

I am not associated with the company, just a user.

On Thu, Aug 17, 2006 at 08:20:22PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Have you tried to use debbugs? I agree with Greg Stark that it's a
> > better fit for our current procedure, while enabling better
> > traceability.
>
> The principal strike against debbugs seems to be that the source code is
> not readily available and/or isn't updated regularly. If we could get
> current sources we'd probably end up maintaining our own fork ... OTOH,
> given all the enthusiasm being expressed in this thread, somebody would
> volunteer to do that no?

Well, actually, you can get the currently running source whenever you
like:

http://bugs.debian.org/debbugs-source/

I got that from one of the bugs listed against debbugs:

http://bugs.debian.org/222077

The problem is that there is no recently packaged version that one can
just quickly install somewhere.

> Other than that not-small problem, I agree that debbugs seems like an
> excellent fit to our existing habits.

Yeah, debbugs is a really good fit here, like for Debian, because of
the overwhelming prevalence of email correspondence compared to any
other kind of communication. If we all used forums ofcourse, debbugs
would suck :)

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>
>> Have you tried to use debbugs? I agree with Greg Stark that it's a
>> better fit for our current procedure, while enabling better
>> traceability.
>>
>
> The principal strike against debbugs seems to be that the source code is
> not readily available and/or isn't updated regularly. If we could get
> current sources we'd probably end up maintaining our own fork ... OTOH,
> given all the enthusiasm being expressed in this thread, somebody would
> volunteer to do that no?
>
> Other than that not-small problem, I agree that debbugs seems like an
> excellent fit to our existing habits.
>
>
>

Well, the enthusiasm was for use, not for maintaining a fork :-)

I had a brief look at the code (literally less than 5 minutes). The good
news is that it is admirably small. A fork isn't a bad idea, though,
especially as a pgfoundry project. I can think of several excellent
candidates for such a project (no names, no pack drill) ;-)

I should mention that it's a perl app.

cheers

andrew

All,

I chatted some with some of the Debian folks who maintain Debbugs. They
thought it would take a significant amount of work to adapt it to
PostgreSQL, in addition to the obvious needs to improve the web interface.

RT has some significant short comings for our project such as not having
good support for tying bugs to versions etc. As people have pointed out,
it's a "Request Tracker", not necessarily a Bug Tracker.

On the other hand, a lot of my personal dislike of BugZilla seems to be
based on being forced to use old versions. A lot of the stuff I hate
about it has been fixed in the current version.

So, the question is whether any of our biggest bug-fixers would dig in
their heels and scream "No!" if we gave BugZilla a try. Comments?

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

>
> So, the question is whether any of our biggest bug-fixers would dig in
> their heels and scream "No!" if we gave BugZilla a try. Comments?
>
>

I could have this setup this weekend should we vote YES :)

Joshua D. Drake

Josh Berkus <josh(at)agliodbs(dot)com> writes:

> On the other hand, a lot of my personal dislike of BugZilla seems to be
> based on being forced to use old versions. A lot of the stuff I hate
> about it has been fixed in the current version.

Does that include it being basically a web-only interface?

I'm listed on various mozilla bugs and occasionally get notifications of
updates but I can't reply to those notifications and I'm not about to fire up
a browser and log in and search for the bug just to add comments.

I expect if you set up a web-based interface it won't be a matter of people
digging in heels so much as just being indifferent to it. And like most
projects the bugs will just accumulate and not get feedback.

Incidentally, does it also fix the issue with the database schema where the
entire set of comments is stored in a single field of a single record and so
when two people comment on a bug at the same time one stomps on the others
changes?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

>
> I expect if you set up a web-based interface it won't be a matter of people
> digging in heels so much as just being indifferent to it. And like most
> projects the bugs will just accumulate and not get feedback.
>
>

And which projects would these be? Oddly enough it might surprise you
that the web has really matured.
All kinds of people use it now. You should really check it out.

;)

Sincerely,

Joshua D. Drake

> Incidentally, does it also fix the issue with the database schema where the
> entire set of comments is stored in a single field of a single record and so
> when two people comment on a bug at the same time one stomps on the others
> changes?
>
>

Gregory Stark <gsstark(at)mit(dot)edu> writes:
> I'm listed on various mozilla bugs and occasionally get notifications of
> updates but I can't reply to those notifications and I'm not about to fire up
> a browser and log in and search for the bug just to add comments.

It's really not that painful: every email bugzilla sends includes the
URL of the bug page. It's one click to visit the page, assuming your
mail and web tools are well enough integrated that you can readily visit
a URL given in text email. (If not, consider joining the 21st century
;-))

I think actually the weak spot of bugzilla for our purposes will be the
problem of transferring original email reports into BZ entries. The
volunteer(s) who do that work are probably going to want a tool better
adapted to that purpose than the standard BZ bug entry page ... but
we'll likely want to do some customization work on our BZ anyway, so
I don't see that as a fatal objection.

The bottom line here is that there will not be any tool that is perfect
for our purposes out-of-the-box. Well, it's all open source, we can
scratch our own itch. What we need more than any specific tool is a
commitment from someone to put effort into adapting the tool to our
needs.

(Given that reality, the quality of the tool's existing source code
needs to figure strongly in our decision. If BZ is still as ugly
as Josh remembers it being, that'd be a strike against it.)

regards, tom lane

Gregory Stark wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>
> > On the other hand, a lot of my personal dislike of BugZilla seems to be
> > based on being forced to use old versions. A lot of the stuff I hate
> > about it has been fixed in the current version.
>
> Does that include it being basically a web-only interface?
>
> I'm listed on various mozilla bugs and occasionally get notifications of
> updates but I can't reply to those notifications and I'm not about to fire up
> a browser and log in and search for the bug just to add comments.
>
> I expect if you set up a web-based interface it won't be a matter of people
> digging in heels so much as just being indifferent to it. And like most
> projects the bugs will just accumulate and not get feedback.

Yea, I'm planning on ignoring the bug tracker until we decide I can stop
doing what I do already.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> Gregory Stark <gsstark(at)mit(dot)edu> writes:
>
>> I'm listed on various mozilla bugs and occasionally get notifications of
>> updates but I can't reply to those notifications and I'm not about to fire up
>> a browser and log in and search for the bug just to add comments.
>>
>
> It's really not that painful: every email bugzilla sends includes the
> URL of the bug page. It's one click to visit the page, assuming your
> mail and web tools are well enough integrated that you can readily visit
> a URL given in text email. (If not, consider joining the 21st century
> ;-))
>
> I think actually the weak spot of bugzilla for our purposes will be the
> problem of transferring original email reports into BZ entries. The
> volunteer(s) who do that work are probably going to want a tool better
> adapted to that purpose than the standard BZ bug entry page ... but
> we'll likely want to do some customization work on our BZ anyway, so
> I don't see that as a fatal objection.
>
> The bottom line here is that there will not be any tool that is perfect
> for our purposes out-of-the-box. Well, it's all open source, we can
> scratch our own itch. What we need more than any specific tool is a
> commitment from someone to put effort into adapting the tool to our
> needs.
>
> (Given that reality, the quality of the tool's existing source code
> needs to figure strongly in our decision. If BZ is still as ugly
> as Josh remembers it being, that'd be a strike against it.)
>
>
>

It is a heck of a lot better then it was. For example, presentation
logic is largely factored out and handed off to TT templates. Personally
I'd like to see the SQL factored out too, but Bugzilla is hardly unique
in having SQL littered across the code. Honestly, this is not your
father's bugzilla. BTW, Josh's memory is of the 1.x series. The 2.x
series is now at 2.22. The code has move a very long way.

There are also tools for email interaction, although they might need to
be beefed up for the likes of some 20th century dwellers :-)

I will check about Greg's complaint about race conditions in updating
comments. My initial impression is that this is no longer so, but I will
get a definite answer.

We certainly have enough perl-heads on our community that we can surely
make it do what we want with little difficulty.

Oh, it can also import some XML too. The DTD is in the source.

cheers

andrew

I wrote:
>
>
> I will check about Greg's complaint about race conditions in updating
> comments. My initial impression is that this is no longer so, but I
> will get a definite answer.
>
>

My impression was correct. Each comment on a bug gets its own row,
marked by bug-id, commenter-id and timestamp.

BTW, there are undoubtedly some infelicities in the schema, but it's not
too bad, and the way the bugzilla code works there is no danger of one
underlying DB platform getting out of synch, as they are all generated
from a single abstract schema.

cheers

andrew

On Aug 17, 2006, at 3:40 PM, Alvaro Herrera wrote:
>> The searching capabilities in debbugs are, well, non-existent,
>> which is
>> a real problem in my mind.
>
> Well, we can set up our own indexing, like Oleg and Teodor have
> done in
> http://www.pgsql.ru/

That seems like quite a hack for something that should be built-in...
it also severely limits searchability. For example, it's very
important to be able to do things like ignore closed bugs when you're
searching.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

On 8/17/06, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> Alvaro Herrera wrote:
> > Have you tried to use debbugs?
>
> If you can find up-to-date source code for debbugs, we might continue
> that line of thought.

http://www.mail-archive.com/debian-debbugs(at)lists(dot)debian(dot)org/msg01266.html

( bzr get http://bugs.debian.org/debbugs-source/mainline/ )

> The searching capabilities in debbugs are, well, non-existent, which is
> a real problem in my mind.

As its mail based, it delegates searching to mail archive search tools.

--
marko

Marko Kreen wrote:
> On 8/17/06, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> Alvaro Herrera wrote:
>> > Have you tried to use debbugs?
>>
>> If you can find up-to-date source code for debbugs, we might continue
>> that line of thought.
>
> http://www.mail-archive.com/debian-debbugs(at)lists(dot)debian(dot)org/msg01266.html
>
> ( bzr get http://bugs.debian.org/debbugs-source/mainline/ )
>
>> The searching capabilities in debbugs are, well, non-existent, which is
>> a real problem in my mind.
>
> As its mail based, it delegates searching to mail archive search tools.
>

Why are we even dabating a system when it has been reported that the
authors believe it is completely unsuitable for use by the PostgreSQL
project?

cheers

andrew

>
> Kenneth Marshall wrote:
> > RT is easy to setup/configure/use and works well with PostgreSQL as
> > the backend.
>
> RT works with Postgres, but I wouldn't say well. All queries
> in RT are generated by a query generator due to a naive
> obsession with database independance. They've achieved
> database independance at the cost of all the queries being
> brain-dead. Fixing the query generator would be a pretty big job.
>

We use RT with PostgreSQL for all internal IT requests and
development/support/doc tasks on a couple products, and there's never
been a problem. Are the queries optimal? no. The alternative might have
been MySQL-only, and that would be worse.

I can't really give a fair estimate on performance, because I'm running
it on a PIII at 800MHz with several other things as well. But it's fast
enough that I'm not screaming for a hardware upgrade.

Regards,
Paul Bort

Andrew,

> Why are we even dabating a system when it has been reported that the
> authors believe it is completely unsuitable for use by the PostgreSQL
> project?

Not *completely*. More that it would take a couple dozen hours of work to
make it good for us, and the resulting version then couldn't be synched
with the Debian version.

Mind you, it would take an equal amount of time to add an e-mail-comment
interface to Bugzilla, but BZ would then probably accept the patch.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

niederland(at)gmail(dot)com wrote:
> Did you look at http://www.atlassian.com/software/jira/

We had discussed that in an earlier round, but it's not free software,
so it's out of the question.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/