How can I check the treatment of bug fixes?

[Joshua D. Drake]

On 05/31/2011 11:05 AM, Alvaro Herrera wrote:

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

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

Sincerely,

Joshua D. Drake


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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Cédric Villemain-3]

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

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

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

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Dimitri Fontaine-7]

Alvaro Herrera <[hidden email]> writes:

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

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

  http://archives.beccati.org/

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

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Josh Berkus]

All,

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

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

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

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

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

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

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

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

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Alvaro Herrera-7]

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

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

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

--
Álvaro Herrera <[hidden email]>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Alvaro Herrera-7]

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

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

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

--
Álvaro Herrera <[hidden email]>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Cédric Villemain-3]

2011/5/31 Josh Berkus <[hidden email]>:

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

GNU succeed to use it, it seems:

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

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

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Peter Eisentraut-2]

On tis, 2011-05-31 at 11:49 +0300, Peter Eisentraut wrote:

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

Done that; I'll report back.


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Dimitri Fontaine-7]

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

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

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Magnus Hagander-2]

On Wed, Jun 1, 2011 at 10:43, Dimitri Fontaine <[hidden email]> wrote:

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

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

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

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Greg Smith-21]

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

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

--
Greg Smith   2ndQuadrant US    [hidden email]   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian]

Josh Berkus wrote:

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

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

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

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

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian]

Greg Stark wrote:

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

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

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian]

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

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

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian]

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

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

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

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

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

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Peter Eisentraut-2]

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

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

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


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Christopher Browne-3]

On Fri, Jun 3, 2011 at 8:42 PM, Bruce Momjian <[hidden email]> wrote:

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

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

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

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers