On Sat, Jul 7, 2012 at 4:48 PM, Bruce Momjian <bruce@momjian.us> wrote:
> 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.
Yes, that's the part that has to be taken care of by that "thin
overlay over email". Some way of grouping multiple threads
together,and somehow keep the end-status of them
(rejected/comitted/wontfix/whatevryouwantocallthestatus). But not
actually keeping a copy of the information anywhere else.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/