Re: Managing the community information stream - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Managing the community information stream
Date
Msg-id 200705151718.l4FHIhe23996@momjian.us
Whole thread Raw
In response to Re: Managing the community information stream  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Managing the community information stream  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Managing the community information stream  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Managing the community information stream  ("Jim C. Nasby" <decibel@decibel.org>)
List pgsql-hackers
Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> 
> > >Also, if I want to discuss renaming something or cleaning up some code,
> > >do we create a tracker item for that or do we have a developer email
> > >list to discuss such issues? 
> > 
> > In the most conformist sense yes, but I can tell you that generally 
> > isn't how CMD does it. How we general do it, is to create a ticket basic 
> > on a topic, that ticket cc's a mailing list and discussion happens in 
> > reply to that cc. So the workflow doesn't actually change. Once 
> > everything is decided we may update the ticket with the final solution, 
> > and then when the work is done we close the ticket.
> > 
> > However, we do it the way we do, because we don't have email 
> > integration. Supposedly (which a small group is currently reviewing) BZ 
> > 3.0 does have email integration so this may change a bit.
> 
> Well, with email integration (as I am envisioning -- I don't know what
> BZ actually implements) it is even better, because you just create a
> ticket, and that sends an email to the list.  Other people can respond
> to that email, which gets saved into the bug without need for further
> action.
> 
> In Debian's bug tracking system, when the bug is created (which is done
> by sending an email to a certain address) it gets a number, and the
> email is distributed to certain lists.  People can then reply to that
> mail, and send messages to 12345@bugs.debian.org and it gets tracked in
> the bug, and you can see all those messages in the bug report.  I
> ass-ume that BZ 3.0 does something similar.

But often a TODO item has multiple threads containing details (often
months apart), and it isn't obvious at the time the thread is started
that this will happen.  Note the number of TODO items that now have
multiple URLs.  How is that handled?

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: Not ready for 8.3
Next
From: Jeff Davis
Date:
Subject: Re: Seq scans roadmap