[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161125031425.gefijvssvygp6pl4@sigill.intra.peff.net>
Date: Thu, 24 Nov 2016 22:14:26 -0500
From: Jeff King <peff@...f.net>
To: "Winkler, Tomas" <tomas.winkler@...el.com>
Cc: Matthieu Moy <Matthieu.Moy@...noble-inp.fr>,
"git@...r.kernel.org" <git@...r.kernel.org>,
"Greg KH (gregkh@...uxfoundation.org)" <gregkh@...uxfoundation.org>,
"Usyskin, Alexander" <alexander.usyskin@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [char-misc-next] mei: request async autosuspend at the end of
enumeration
On Thu, Nov 24, 2016 at 10:37:14PM +0000, Winkler, Tomas wrote:
> > > > Cc: <stable@...r.kernel.org> # 4.4+
> > >
> > > Looks like git send-email is not able to parse this address correctly
> > > though this is suggested format by Documentation/stable_kernel_rules.txt.
> > > Create wrong address If git parsers is used : 'stable@...r.kernel.org#4.4+'
> > >
> > > Something like s/#.*$// is needed before parsing Cc:
> >
> > This should be fixed by e3fdbcc8e (parse_mailboxes: accept extra text after
> > <...> address, 2016-10-13), which will be released next week as part of v2.11. As
> > a workaround, you can also install the Mail::Address perl module. See [1] for
> > the gory details.
>
> Thanks for update, I failed to understand from the thread though what
> decision was actually applied, I will look at the patch itself. I've
> tried to install Mail::Address and it fixes the actual address, but it
> appends the # 4.4+ suffix into the name as also mentioned in the
> thread, which doesn't fit the stable rules doc.
The patch just brings parity to the Mail::Address behavior and git's
fallback parser, so that you don't end up with the broken
stable@...r.kernel.org#4.4+ address. Instead, that content goes into the
name part of the address.
It sounds like you want the "# 4.4+" to be dropped entirely in the
rfc822 header. It looks like send-email used to do that, but stopped in
b1c8a11c8 (send-email: allow multiple emails using --cc, --to and --bcc,
2015-06-30).
So perhaps there are further fixes required, but it's hard to know. The
input isn't a valid rfc822 header, so it's not entirely clear what the
output is supposed to be. I can buy either "drop it completely" or
"stick it in the name field of the cc header" as reasonable.
-Peff
Powered by blists - more mailing lists