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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
