Re: Getting a bug tracker for the Postgres project
От | Joe Abbate |
---|---|
Тема | Re: Getting a bug tracker for the Postgres project |
Дата | |
Msg-id | 4DE3AF43.2070900@freedomcircle.com обсуждение исходный текст |
Ответ на | Re: Getting a bug tracker for the Postgres project (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
Hi Magnus, On 05/30/2011 08:45 AM, Magnus Hagander wrote: > It's fine that a bug tracker *tracks* bugs. It should not control > them. That's not how this community currently works, and a lot of > people have said that's how they want it to stay (at least for now). If I may belabor the point, what do you see as an example of "controlling" the bugs? To put some context, there could be at least three ways a bug could be closed when someone commits a patch that fixes (or claims to fix) a bug: a. The committer has to use a web interface to indicate the bug is closed b. The committer has to send an email to a mail interface c. The commit message gets routed to a mail interface that, seeing something like "bug #1234" in the first line, automatically closes the bug Based on the discussion so far, it's obvious that option b is more desired than a (where the tracker is, in a sense, controlling *you*), but is option c --while presumably more desirable since there's one less thing to do or remember-- an instance of "control", since the tracker takes an automatic action? Or do you want the tracker *not* to require or take any of the actions, i.e., let someone/thing other than the committer/commit message worry about tracking the bug's status, leaving it up to volunteers, as Tom said? Joe
В списке pgsql-hackers по дате отправления: