Re: RFE: use patchwork to submit a patch
On Mon, Nov 11, 2019 at 10:35:10AM +0100, Dmitry Vyukov wrote: > On Sat, Nov 9, 2019 at 5:31 AM Theodore Y. Ts'o wrote: > > Essentially format=flowed is only supposed to be used when it's > > considered OK for the receiver to reflow (or not) the lines any darned > > way it wants. > But for me the point re email still stands: why are we even spending > time discussing this? Why are there such extensions with MAY status? > If one doesn't care if the received with recover the original message > or not, why caring adding/specifying these "format=flowed; > delsp=yes"?... > Obviously somebody in the middle got confused about these flowed/delsp > as well and either assumed that they are MUST or assumed that > preserving precise text for emails is just never important... Not sure if you're looking for a serious answer here or not and it's not really your point but the use case for format=flowed is for plain text mails. The sending MUA should flow the mail into 80 columns so it will render OK as text but if something wants to reflow (eg, to fit within a window) like it would for a paragraph in HTML mail then it can. It's optional so that things where the formatting is important don't get disrupted. > Regarding another mail agent: again this only proves the point for me: > this is what tool developers are forced to be spending their resources > on, rather then working on adding more useful features... > I don't even know where to start re switching mail transport; how much > the switch will cost? what are other transport costs in the long term > maintenance? what are their problems? We're not going to get away from interoperability problems no matter what we use, especially if we are mixing things intended for human and machine consumption. signature.asc Description: PGP signature ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Sat, Oct 12, 2019 at 09:19:11AM +0200, Greg KH wrote: > On Fri, Oct 11, 2019 at 05:35:53PM -0400, Konstantin Ryabitsev wrote: > > 1. provide a way for someone to submit a patch using a web interface (but > > still in a way that From: is their corporate ID) > If you do this, what happens when a maintainer/reviewer responds to that > patch and says "looks good, but can you change X and resend it?" > How will they get that message if it didn't go through their email > system? How will they be able to respond to it? If they're using their work e-mail address like Konstantin says they'll get the reply there. Probably any response from them will be some top posted thing with HTML but this happens often enough currently - people often use git send-email or something to send but continue using a mail setup that's not really what's expected for kernel work. Usually it's not the end of the world even if people get a bit grumpy at them. signature.asc Description: PGP signature ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?
On Mon, Jul 01, 2019 at 11:35:48AM +1000, Andrew Donnellan wrote: > Regarding adding it to downloaded mboxes, if we do that I'd like it to be a > separate option. A single patch can also land in patchwork multiple times > via various lists, so the URL will depend on which project you're looking > at. At least for the kernel there's a redirector lore.kernel.org/r/msgid which is list agnostic. I'm not sure it matters much which of muiltiple list archives get used though, if people really want this presumably just having any old link should be enough. signature.asc Description: PGP signature ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
