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: