Re: Bug tracker tool we need

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Bug tracker tool we need
Дата
Msg-id CABUevEzewZNRezMKbH9+8JT7hrNEnq5bFbYRomhuFF-C=XBMbw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bug tracker tool we need  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Bug tracker tool we need  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Bug tracker tool we need  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Gurjeet Singh
Дата:
Сообщение: Allow replacement of bloated primary key indexes without foreign key rebuilds
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Bug tracker tool we need