Re: Bug tracker tool we need

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Daniel Farina <daniel(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug tracker tool we need
Date: 2012-07-07 10:59:02
Message-ID: CABUevEx7Gsomcamiu2UAB8hndpgfG=QZ9o1bbNE27y2yK2ELgA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout
<kleptog(at)svana(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-07-07 11:16:49 Re: patch: inline code with params
Previous Message Martijn van Oosterhout 2012-07-07 10:48:51 Re: Bug tracker tool we need