On Sat, Jul 07, 2012 at 04:45:42PM +0200, Magnus Hagander wrote: > >> 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.
Imagine a case where a single message-id could show all emails before and after that refer to it, and all commits and release note text associated with it. I think there are going to be cases where multiple email threads all represent the same item, of course, and might not be linked via email references. -- 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
