On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian <bruce@momjian.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.
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.
--
fdr
