Re: mailing list redirect for bug numbers?

On Thu, Jan 17, 2019 at 7:28 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> > On Thu, Jan 17, 2019 at 4:42 PM Stephen Frost <sfrost(at)snowman(dot)net>
> wrote:
> > > > Doing that in pglister seems like a terrible idea. But if we want
> to, we
> > > > could do it in the actual bug generation form, sure. That would be
> > > trivial.
> > >
> > > Doing it in the bug generation form would only be half a solution
> > > though. Beyond the concern about pglister being too 'PG' specific,
> > > what's the issue with having it able to add such headers..?
> >
> > Sure, but I fail to see the *gain* with having it. If the contents of the
> > header is based on what's already in the email, it doesn't add any new
> > information. The bug number is *already* in the message, why copy it?
>
> Uhhh, no, the point here was to assign bug numbers for emails to -bugs
> which *don't* go through the bugs form and therefore didn't have the bug
> number info in the message.
>

Without having the ability to properly merge bugs and to structured cross
referencing and such, I think that's a really bad idea. That's going to
cause more problems than it's fixing.

>
> Doing it for the ones that *did* go through the form might be nice
> because it'd add consistency as to where to find the bug number and that
> could possibly even be done across replies that might have changed the
> Subject line and removed the bug and such.
>

Eh. AFAIK there is no way to add a header that MUAs making replies are
going to add to the reply as well.

Our one chance to thread together emails are in the References headers,
which is what the archives do today. A header like this would have zero
effect on that.

It *is* consistent where to find the bug number. The only differences we've
done in the past 20 years are change from "Bug" to "BUG" and add a : after
the number....

> > But we can't do that backdated on existing mails. In the archives
> they're
> > > > immutable. So they'd be for new emails only. So I'm not sure it would
> > > > actually help very much?
> > >
> > > We could certainly provide the mapping for old emails even if we don't
> > > want to actually change the existing emails (although I'm not entirely
> > > convinced it'd be such a bad idea to include the bug numbers
> somehow..),
> > > and, really, we're talking about commits going forward, so is the issue
> > > that old emails don't have it actually a problem? New emails would and
> > > the commit log moving forward is much more likely to reference new bugs
> > > than old..
> >
> > Right. I'm not saying we shouldn't provide the mapping for old ones -- we
> > definitely should. In fact I've gotten pretty far on the road of
> > backfilling that with some tricky regepx (and yes, we have things like
> > duplicate bugs with the same bug id and things in the archives -- the
> kind
> > of stuff that happens when you don't actually store things in, say, a
> > database).
> >
> > But that's unrelated to providing an additional custom header to an email
> > that already contains that information.
>
> For emails from the bugs form, having the bug number in a header
> (instead of just the subject) seems like it could be independently
> useful, but the discussion here was about providing a way for bug
> numbers to be assigned based on just an inbound email- one that didn't
> use the form.
>

Doing that at the form addition is trivial, and if people think it's useful
I'll be happy to add that. I just don't see how it would be useful, but if
others do..

And no, the issue here was to redirect from bug numbers to the archives.
Everything else is scope creep :P

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>