Re: Bug tracker tool we need - Mailing list pgsql-hackers
From | Magnus Hagander |
---|---|
Subject | Re: Bug tracker tool we need |
Date | |
Msg-id | CABUevEzewZNRezMKbH9+8JT7hrNEnq5bFbYRomhuFF-C=XBMbw@mail.gmail.com Whole thread Raw |
In response to | Re: Bug tracker tool we need (Bruce Momjian <bruce@momjian.us>) |
Responses |
Re: Bug tracker tool we need
Re: Bug tracker tool we need |
List | pgsql-hackers |
On Sat, Jul 7, 2012 at 1:46 AM, Bruce Momjian <bruce@momjian.us> wrote: > 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@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. > > 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). I've never thought of it in terms of "friction", but I think that term makes a lot of sense. And it sums up pretty much one of the things that I find the most annoying with the commitfest app - in the end it boils down to the same thing. I find it annoying that whenever someone posts a new review or new comments, one has to *also* go into the CF app and add them there. Which leads to a lot of friction, which in turn leads to people not actually putting their comments in there, which decreases the value of the tool. Don't get me wrong - the cf app is a huge step up from no app at all. But it's just not done yet. >> 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. Yup, it's being worked on. FWIW, somewhere there's a piece of bugtracker code in a dusty corner that I once wrote that was intended as a prototype for something sitting as this "thin overlay on top of email". It worked reasonably well, and then crashed and burned when it came to the cross-month thread splitting. Once that is fixed (and unlike most times before (yes, there are exceptions) it's being actively worked on right now), it could be dusted off again - or something else could be built on top of that capability. > I feel we have to be honest in what our current development process does > poorly. +1. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
pgsql-hackers by date: