Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)
On Wed, 13 Jun 2018 15:27:31 +0200, Andreas Grünbacher wrote: > All of that may be correct, but those headers apparently do break > email based patch reviewing on Thunderbird and Gmail now, and that's > not very likely to change. If we continue with our current practice, > we'll end up frustrating users. On top of that, i we make this an > optional feature, quilt users may think that using that option is a > good idea when they will actually break their recipients' workflows. > As Thomas Gleixner wrote in the other thread, most recipients will > already have a way to deal with messages from other sources that don't > include patch filenames, so let's just get rid of Content-Disposition > headers in quilt for good. It always feels bad to me to work around an issue in one piece of software when the bug is clearly in another piece of software. I'm not sure why fixes on the correct side of the problem should be unlikely. The behavior is clearly broken and against the RFC, and there may be other sources than quilt triggering the bug. Thunderbird is open source, the problem is identified, it shouldn't be that hard to fix it. Gmail is a different story, of course, but I guess there are some developers maintaining it too. That being said... I agree that recipients of such e-mails most likely already have an alternative solution in place for non-quilt sources, so probably removing the Content-Disposition header is not going to cause too much trouble. So feel free to go ahead and remove it if you think this is the best thing to do. If some users complain about the change, I'll let you deal with them ;-) -- Jean Delvare SUSE L3 Support
Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)
On Wed, Jun 13, 2018 at 6:27 AM Andreas Grünbacher wrote: > > All of that may be correct, but those headers apparently do break > email based patch reviewing on Thunderbird and Gmail now, and that's > not very likely to change. I do want to point out that at least for me, it's not a very big annoyance. It would be sad if people who actually_use_ quilt lose a feature they use for this. I've seen it twice in the last few months, so it's not like it's all that noticeable. It's a bit annoying when it happens, but it's not a show-stopper. Either I don't interact with a lot of quilt users, or (quite likely) people don't always use quilt itself to then send the patches (the same way I don't use git send-email to send patches even though I obviously use git). Linus
Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)
Jean,
2018-06-13 14:32 GMT+02:00 Jean Delvare :
> Hi Peter, Linus, Andreas,
>
> On Tue, 12 Jun 2018 19:14:20 +0200, Peter Zijlstra wrote:
>> On Tue, Jun 12, 2018 at 09:47:34AM -0700, Linus Torvalds wrote:
>>
>> > I do note how quilt emails are really hard to read, because that:
>> >
>> > Content-Disposition: inline
>> >
>> > makes gmail think it's flowed.
>> >
>> > Which works horribly badly for patches, surprise surprise.
>> >
>> > So I really wish quilt wouldn't do that. It does smell like a gmail
>> > bug, but at the same time, why would you use "Content-Disposition:
>> > inline" when you don't have an actual multi-part email? So I do blame
>> > quilt too for sending nonsensical headers.
>> >
>> > (Yes, yes, I see the "It is permissible to use Content-Disposition on
>> > the main body" in the RFC. But the RFC also makes it clear that it
>> > actually matters for how things are presented, so saying "ok, I'll do
>> > flowed" seems equally insane and equally technically RFC-compliant)
>>
>> Quilt people, anything that can be done about that?
>
> The purpose of the Content-Disposition header is to let quilt store the
> original patch file name, so that the recipient can save the email as a
> patch file having the exact same name as the sender was using, to make
> communication between developers easier. This is the reason why the
> header is being added despite the email not being multi-part. As Linus
> found out already, RFC 2183 allows that. The RFC also explicitly allows
> the use of a filename parameter for inline parts (see section 2.3.)
>
> Using "attachment" instead of "inline" would presumably force the user
> to save the patch to a file before being able to read it, or, at least,
> to take additional actions in the MUA to convince it to display the
> contents inline regardless of what the Content-Disposition header
> says. This is clearly not desirable.
>
> We could try specifying the filename directly, without the "inline"
> keyword, however that would no longer comply with the RFC
> ("disposition-parm" is optional, but "disposition-type" is mandatory)
> and I am afraid that some MUA implementations would either default to
> disposition-type "attachment" in this case, or ignore the header
> altogether.
>
> I'm not sure I understand what "flowed" means in this context. If you
> mean that gmail breaks the formatting of the patch, I would say that
> gmail is infringing the RFC, which clearly stipulates at the beginning
> that the Content-Disposition header field is only about telling the MUA
> which parts should be displayed immediately and which parts should not,
> and not about presentation issues.
>
> Considering that "inline" is the default for a non-multi-part message,
> any MUA which changes its behavior in the presence of
> "Content-Disposition: inline" is bugged in my opinion.
All of that may be correct, but those headers apparently do break
email based patch reviewing on Thunderbird and Gmail now, and that's
not very likely to change. If we continue with our current practice,
we'll end up frustrating users. On top of that, i we make this an
optional feature, quilt users may think that using that option is a
good idea when they will actually break their recipients' workflows.
As Thomas Gleixner wrote in the other thread, most recipients will
already have a way to deal with messages from other sources that don't
include patch filenames, so let's just get rid of Content-Disposition
headers in quilt for good.
Andreas
Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)
Hi Peter, Linus, Andreas,
On Tue, 12 Jun 2018 19:14:20 +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 09:47:34AM -0700, Linus Torvalds wrote:
>
> > I do note how quilt emails are really hard to read, because that:
> >
> > Content-Disposition: inline
> >
> > makes gmail think it's flowed.
> >
> > Which works horribly badly for patches, surprise surprise.
> >
> > So I really wish quilt wouldn't do that. It does smell like a gmail
> > bug, but at the same time, why would you use "Content-Disposition:
> > inline" when you don't have an actual multi-part email? So I do blame
> > quilt too for sending nonsensical headers.
> >
> > (Yes, yes, I see the "It is permissible to use Content-Disposition on
> > the main body" in the RFC. But the RFC also makes it clear that it
> > actually matters for how things are presented, so saying "ok, I'll do
> > flowed" seems equally insane and equally technically RFC-compliant)
>
> Quilt people, anything that can be done about that?
The purpose of the Content-Disposition header is to let quilt store the
original patch file name, so that the recipient can save the email as a
patch file having the exact same name as the sender was using, to make
communication between developers easier. This is the reason why the
header is being added despite the email not being multi-part. As Linus
found out already, RFC 2183 allows that. The RFC also explicitly allows
the use of a filename parameter for inline parts (see section 2.3.)
Using "attachment" instead of "inline" would presumably force the user
to save the patch to a file before being able to read it, or, at least,
to take additional actions in the MUA to convince it to display the
contents inline regardless of what the Content-Disposition header
says. This is clearly not desirable.
We could try specifying the filename directly, without the "inline"
keyword, however that would no longer comply with the RFC
("disposition-parm" is optional, but "disposition-type" is mandatory)
and I am afraid that some MUA implementations would either default to
disposition-type "attachment" in this case, or ignore the header
altogether.
I'm not sure I understand what "flowed" means in this context. If you
mean that gmail breaks the formatting of the patch, I would say that
gmail is infringing the RFC, which clearly stipulates at the beginning
that the Content-Disposition header field is only about telling the MUA
which parts should be displayed immediately and which parts should not,
and not about presentation issues.
Considering that "inline" is the default for a non-multi-part message,
any MUA which changes its behavior in the presence of
"Content-Disposition: inline" is bugged in my opinion.
--
Jean Delvare
SUSE L3 Support
Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)
On Tue, Jun 12, 2018 at 09:47:34AM -0700, Linus Torvalds wrote: > I do note how quilt emails are really hard to read, because that: > > Content-Disposition: inline > > makes gmail think it's flowed. > > Which works horribly badly for patches, surprise surprise. > > So I really wish quilt wouldn't do that. It does smell like a gmail > bug, but at the same time, why would you use "Content-Disposition: > inline" when you don't have an actual multi-part email? So I do blame > quilt too for sending nonsensical headers. > > (Yes, yes, I see the "It is permissible to use Content-Disposition on > the main body" in the RFC. But the RFC also makes it clear that it > actually matters for how things are presented, so saying "ok, I'll do > flowed" seems equally insane and equally technically RFC-compliant) Quilt people, anything that can be done about that?
