Re: Managing the community information stream

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Managing the community information stream
Date: 2007-05-15 17:18:42
Message-ID: 200705151718.l4FHIhe23996@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)bugs(dot)debian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2007-05-15 17:25:35 Re: Seq scans roadmap
Previous Message Stefan Kaltenbrunner 2007-05-15 17:13:54 Re: Not ready for 8.3