Re: Bug tracker tool we need - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Bug tracker tool we need
Date
Msg-id CABUevEx7Gsomcamiu2UAB8hndpgfG=QZ9o1bbNE27y2yK2ELgA@mail.gmail.com
Whole thread Raw
In response to Re: Bug tracker tool we need  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Bug tracker tool we need
List pgsql-hackers
On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout
<kleptog@svana.org> wrote:
> On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote:
>> 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.
>
> Well, if that's the issue then there are well known solutions to that.
> Give each commitfest entry a tag, say, CF#8475 and add a bot to the
> mail server that examines each email for this tag and if found adds it
> to the CF app.

So now you moved the friction over to the initial submitter instead,
because he/she how has to get this tag before posting the patch in the
first place. And this would need to happen before it's even known if
this needs to go on a CF or will just be approved/rejected directly
without even getting there.

That's not to say it's a horrible idea, it's just to say that things
are never as easy as they first look.

BTW, the *bigger* issue with this path is that now we suddenly have
different kinds of identifiers for different things. So you have a bug
id, and a cf id, and they are different things. So you're going to end
up tagging things with multiple id's. etc. That part goes to show that
we cannot just "solve" this in one part of the workflow. We can put in
useful workarounds that go pretty far - like the cf app - but we
cannot get the "complete solution". OTOH, maybe we never can get the
complete solution, but we should work hard at not locking into
something else.


> This could then easily track commit messages, emails on mailing list
> and even bug reports.  (For example, someone replys to a bug report
> with "See CF#8484" and then a reference to the bug thread gets pushed
> into the CF app.)

All of these things are already "emails on mailing lists", after all...


> It's also a searchable identifier, which is also useful for google.

Yes, I agree that having a searchable and *referencable* identifier is
a good thing. In fact, one of the main reasons to do something like
this. Right now we just tell people "look in the archives", and that
doesn't work. Heck, *I* search them quite often and I still don't
understand how some people can find things so quickly :)

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Bug tracker tool we need
Next
From: Pavel Stehule
Date:
Subject: Re: patch: inline code with params