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 > <klep...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
