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
