Re: Managing the community information stream

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Managing the community information stream
Дата
Msg-id 200705151718.l4FHIhe23996@momjian.us
обсуждение исходный текст
Ответ на Re: Managing the community information stream  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: Not ready for 8.3
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Seq scans roadmap