Re: Getting a bug tracker for the Postgres project

On Tue, May 31, 2011 at 07:08, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)cc> wrote:
> On 05/31/2011 05:42 AM, Tom Lane wrote:
>> Kim Bisgaard <kim+pg(at)alleroedderne(dot)adsl(dot)dk> writes:
>>> On 2011-05-30 04:26, Greg Stark wrote:
>>>> My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to that email.
>>
>>> Just checked bugzilla's list of features and they *now* lists that as supported:
>>
>>>> File/Modify Bugs By Email
>>>>
>>>> In addition to the web interface, you can send Bugzilla an email that will create a new bug, or will modify an existing bug. You can also
>>>> very easily attach files to bugs this way.
>>
>> The claim is there all right, but the feature seems spectacularly
>> undocumented otherwise.  I wanted to see if it worked like debbugs
>> (ie, you just cc: some mail to the bug tracker), but there's no
>> information about exactly how to use it.
>
> Depends on what exactly you are looking for...
>
> * that feature relies on finding a valid bugid in the subject, if it
> finds one it will add the email ass a comment
> * if you would prefer something like nnnnnn-bug(at)tracker(dot)postgresql(dot)org
> for adding to existing bugs, that would be a trivial thing to add as a
> feature(have the MTA split the localpart and pass it as a parameter in
> the pipe-transport to the email_in.pl script)
> * the challenge is more about creating "new" bugs, because for that you
> need a bz account (or maybe a community account in our case) by default.
> We could certainly modify the feature so that it will autocreate bz
> accounts as soon as we see a new emailaddress sending email in but that
> will be fairly hard to control spamwise.

Yikes. (On the very last point there)

But.

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.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/