On tis, 2011-05-31 at 10:36 +0200, Magnus Hagander 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?
Maybe you are assuming that there is a single workflow that everyone wants. So far we know that most people want to work by email and want to know that a bug is closed. Is there more detail than that that we can extract? > 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. Well, that is not a workflow either, it's approaching the issue by proposing an implementation. Nothing says that an existing or new system doesn't work exactly like that. I would be concerned about the search capabilities of such a system, however. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
