Re: Bug tracker tool we need

On Fri, Jul 06, 2012 at 03:41:41PM -0700, Daniel Farina wrote:
> On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > I think our big gap is in integrating these sections. There is no easy
> > way for a bug reporter to find out what happens to his report unless the
> > patch is applied in the same email thread as the report. It is hard for
> > users to see _all_ the changes made in a release because the release
> > notes are filtered.
> >
> > Our current system is designed to have very limited friction of action,
> > and this give us a high-quality user experience and release quality, but
> > it does have limits in how well we deal with complex cases.
>
> I do basically agree with this. I was reflecting on the bug tracker
> issue (or lack thereof) for unrelated reasons earlier today and I
> think there are some very nice things to recommend the current
> email-based system, which are the reasons you identify above. Perhaps
> the area where it falls down is structured searches (such as for
> "closed" or "wontfix") and tracking progress of related, complex, or
> multi-part issues that span multiple root email messages.

I normally assume "friction" is just something that slows you down from
attaining a goal, but open source development is only _possible_ because
of the low friction communication available via the Internet. It isn't
that open source development would be slower --- it would probably not
exist in its current form (think shareware diskettes for an
alternative).

So, while it is hopeful to think of a bug trackers as just slowing us
down, it might really alter our ability to develop software. Yes, I
know most other projects use bug trackers, but I doubt their development
and user interactions are the same quality as ours. On the flip side,
for complex cases, some of our user interactions are terrible.

> Maybe just using the message-ids to cross reference things (or at
> least morally: perhaps a point of indirection as to collapse multiple
> bug reports about the same thing, or to provide a place to add more
> annotation would be good, not unlike the CommitFest web application in
> relation to emails) is enough. Basically, perhaps an overlay
> on-top-of email might be a more supple way to figure out what process
> improvements work well without committing to a whole new tool chain
> and workflow all at once.

I know there is work to allow cross-month email archive threading, and
that might help.

I feel we have to be honest in what our current development process does
poorly.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +