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

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.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +