On Fri, Jul 06, 2012 at 03:41:41PM -0700, Daniel Farina wrote: > On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian <br...@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). 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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
