Re: Getting a bug tracker for the Postgres project
| От | Robert Haas |
|---|---|
| Тема | Re: Getting a bug tracker for the Postgres project |
| Дата | |
| Msg-id | BANLkTimhwC1s5K7mZqeFQ+cVHoGc9cVU+g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Getting a bug tracker for the Postgres project (Magnus Hagander <magnus@hagander.net>) |
| Ответы |
Re: Getting a bug tracker for the Postgres project
|
| Список | pgsql-hackers |
On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <magnus@hagander.net> wrote: > I get the feeling we're approaching this backwards. Wouldn't the > normal way to do it be to define the workflow we *want*, and then > figure out which bugtracker works for that or requires the least > changes for that, rather than to try to figure out which bugtracker we > want and then see how much we have to change our workflow to match? > The previous way is kind of what we did with the CF app, and while I > have some things I want fixed in that one they are details - the > process seems to work fine. > > So in order to start a brand new bikeshed to paint on, have we even > considered a very trivial workflow like letting the bugtracker > actually *only* track our existing lists and archives. That would > mean: > > * Mailing lists are *primary*, and the mailing list archives are > *primary* (yes, this probably requires a fix to the archives, but that > really is a different issue) > * New bugs are added by simply saying "this messageid represents a > thread that has this bug in it", and all the actual contents are > pulled from the archives > * On top of this, the bug just tracks metadata - such as open/closed > more or less. It does *not* track the actual contents at all. > * Bugs registered through the bugs form would of course automatically > add such a messageid into the tracker. That's pretty much exactly what I think would be most useful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: