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

On Sat, Jul 7, 2012 at 4:42 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Sat, Jul 07, 2012 at 12:59:02PM +0200, Magnus Hagander wrote:
>> 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.
>
> Yes, we would almost need to number each incoming email, and use that
> reference all the way through to the release note item text. or at least
> a searchable git log of the release note commits.

Which we in a lot of ways have - we have the messageid. But we need a
nicer interface for people to use than that... But that serves pretty
well as an underlying identifier.

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