Re: RFE: use patchwork to submit a patch
On Fri, 11 Oct 2019 19:00:09 -0400 Steven Rostedt wrote: > > > > As someone who has to deal with a corporate busted mail server. > > > > I agree mailing patches is a barrier to entry for many people today. > > > > > > Hmm, and I wonder what company fosters so many issues with doing that > > > today? :-/ > > > > > > /me notices that Stephen uses his personal email account ;-) > > > > Your current employer also defaults to a crappy link replacer on most > > emails :-) > > Yes, because they use Stephen's employer's crappy email servers. Yes, my life is too short to fight with corporate stuff. There is a security first mindset which is good but gets in the way. The current generation of Internet standard mail protocols does not have enough security to be allowed. It does bring up that any new workflow has to have security protocol and threat model as part of its design. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Fri, Oct 11, 2019 at 09:23:08PM +, Eric Wong wrote: (This is the same reason I generally disagree with Eric Wong about preserving SMTP as the primary transmission protocol -- I've heard lots of complaints both from kernel developers and especially from people trying to contribute to CAF about corporate policies actually making it impossible to submit patches -- and no, using a different mail server is not a possibility for them because it can be a firing offense under their IT AUP rules.) I'm not opposed to a webmail interface tailored to kernel hacking which does stuff like checkpatch.pl and get_maintainer.pl before sending (similar to your patchwork proposal and gitgadgetgadget). That would get around security appliances but SMTP would still be used in the background. Or offer full-blown HTTPS webmail + IMAP + SMTP access like any other webmail provider + checkpatch + get_maintainer helpers. Well, this is the bit where I say that it may not be allowed by corporate rules. I see this all the time in CAF/Android world where companies *require* that all email goes through their SMTP server so that it can be properly logged (often for legal reasons). And it is often equally required that any code submissions come from per...@corporate.com and not per...@free-email-provider.com for License/CLA reasons, so setting up a webmail server is not a solution either. This is basically why SMTP sucks in my view -- and it's worthless trying to pick fights with IT departments, because they are told to do so by lawyers. So, I want to take SMTP out of the equation: 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) 2. use individual git feeds as a way to send out patches instead of always being secondary to SMTP -K ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Fri, 11 Oct 2019 12:11:53 -0700 (PDT) David Miller wrote: > From: Mauro Carvalho Chehab > Date: Fri, 11 Oct 2019 15:59:49 -0300 > > > I can't see how just adding a web interface like github/gitlab > > would solve any of the above. I mean, the submitter will still > > need to write a proper subject/description before submitting the > > patch to the web interface, add the tags, etc. > > You can actually codify the various fields into a web form with > help texts etc. > > Things that are mandatory can even be marked required and people > can't even submit a PR without Signed-off-by: for example. As someone who has to deal with a corporate busted mail server. I agree mailing patches is a barrier to entry for many people today. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Fri, Oct 11, 2019 at 10:57:02AM +0200, Greg KH wrote: So other than that minor thing, sounds interesting. It's hard to determine just how difficult the whole "set up git and send a patch out" process is for people these days given the _huge_ numbers of new contributions we keep getting, and the numerous good tutorials we have created that spell out exactly how to do this. So you might be "solving" a problem that we don't really have. It's hard to tell :( It is interesting that there are split views on this. The main reason why I was thinking about it was because the topic came up a few times already. For example, in a conversation last year on ksummit-discuss: https://lore.kernel.org/ksummit-discuss/ecadff3fd767c149ad96a924e7ea6eaf7c1ea...@usculxmsg01.am.sony.com/ Tim Bird mentioned that Sony developers couldn't send/receive patches because their corporate mail server rewrote all links to go through some kind of security appliance verification. If you read that thread, what we are discussing now is what I suggested we did then -- a web tool that could take corporate SMTP servers out of the equation. (This is the same reason I generally disagree with Eric Wong about preserving SMTP as the primary transmission protocol -- I've heard lots of complaints both from kernel developers and especially from people trying to contribute to CAF about corporate policies actually making it impossible to submit patches -- and no, using a different mail server is not a possibility for them because it can be a firing offense under their IT AUP rules.) I know this is a pretty big RFE, and I would like to hear your thoughts about this. If there is general agreement that this is doable/good idea, I may be able to come up with funding for this development as part of the overall tooling improvement proposal. The workflow seems sane, and matches what most people do today, with the exception that it "solves" the git send-email issue, right? Is that our biggest barrier? Well, I can't really speak from my extensive experience as a kernel developer, but I *have* submitted patches to Documentation/* before. This happens infrequently enough that I basically have to relearn the whole process from scratch, and it *is* a lot of steps. I can't fault people who are only familiar with the GitHub way of doing things when they complain that this process is a challenge for them. Not everyone submitting changes to the kernel are going to be highly skilled and comfortable with the terminal and command-line tools. They may be submitting a documentation fix, or it can be a driver developer who never leaves Visual Studio submitting a small bugfix so their driver works better in Linux. I would recommend interviewing some of the recent kernel mentor project and outreachy applicants first, to try to determine exactly what their problems, if any, were with our development process. If they say that this type of tool/workflow would have saved them hours of time and energy, then that's a great indication that we should try to do this. I don't disagree and Shuah's comments are very valuable here. However, I would argue that these folks don't necessarily represent the target audience for this tool. They may be newbies, but they join these initiatives with the goal of spending significant time with the kernel and its code, so they don't mind the effort of learning the proper way of submitting patches. I'm thinking of someone who needs to submit an occasional contribution once every six months and to whom this document is both long and daunting: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html. -K ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
From: Mauro Carvalho Chehab Date: Fri, 11 Oct 2019 15:59:49 -0300 > I can't see how just adding a web interface like github/gitlab > would solve any of the above. I mean, the submitter will still > need to write a proper subject/description before submitting the > patch to the web interface, add the tags, etc. You can actually codify the various fields into a web form with help texts etc. Things that are mandatory can even be marked required and people can't even submit a PR without Signed-off-by: for example. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
From: Steven Rostedt Date: Fri, 11 Oct 2019 14:01:08 -0400 > Thus, if we want people to send us their fixes, we better keep just > an email with a patch the lowest bar for entry. I argue that for people coming into the software engineering world today, a PR is the lowest bar for entry. And email is the exact opposite, _especially_ our way of doing email. Because it IS NOT just an email with a patch. It is an email with a specific Subject line format, with various fields. Some field are optional and some are mandatory, and it also depends upon which tree you are targetting. Then there is the commit message which has content and formatting requirements. And then there are the tags, of various types and flavors, and the context (which is sometimes subtle) determines which of those tags are relevant and how they should be filled in. The various other standard email fields like TO: and CC: have to be set a certain way otherwise the patch won't even be looked at. If you think all of this stuff is a low barrier to entry you are frankly kidding yourself. It is ONLY a low barrier to entry for an experienced Linux kernel developer. Full stop. You are not helping casual contributors with this "simple" email based submission method. It is understood and easy us, but nobody else. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH] parser: Unmangle From: headers that have been mangled for DMARC purposes
On Freitag, 11. Oktober 2019 06:50:14 CEST Andrew Donnellan wrote: > On 11/10/19 3:36 pm, Andrew Donnellan wrote: > > It would be nice if Mailman could adopt X-Original-Sender too. As it is, > > (which I have gone ahead and reported as > https://gitlab.com/mailman/mailman/issues/641) Not stopping you from doing that, since I still think that it'd be helpful if mailman added some kind X-Original-Sender header in case the email has to be munged for some reason. Just some notes about status & consensus we had: 1. On GNU lists the default mailman settings are now to prevent munging in first place (if possible): https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg00416.html 2. If any list member has the "nodup" mailman option turned on, mailman would still munge emails due to that. Ian (on CC) worked on a patch to override that individual user setting automatically if necessary: https://bugs.launchpad.net/mailman/+bug/1845751 3. On git side it was suggested to add some kind of "always_use_in_body_from" option: https://public-inbox.org/git/20190923222415.ga22...@sigill.intra.peff.net/ Unless that git option exists, this little trick proofed as usable workaround for git patch submitters suffering from munging: https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg00932.html 4. MTA's should also address this DKIM issue more accurately. For instance Exim is currently by default filling the "dkim h=..." header with "all header names listed in RFC4871 will be used, whether or not each header is present in the message": https://www.exim.org/exim-html-current/doc/html/spec_html/ch-dkim_and_spf.html That "h=" tag in email's dkim header lists all email headers which were included by MTA for signing the message. However IMO MTA's should not list any "List-*" header name in "dkim h=..." (at least not if not present in message), otherwise mailman is forced to munge any of such messages when adding its required List-* headers. BTW section 5.5. (page 38) of that RFC4871 actually sais these headers "SHOULD be included in the signature, if they are present in the message being signed". For now you can override this setting, e.g. by using Exim's "dkim_sign_headers" setting and providing your own list of header names, but from security point of view that's suboptimal, since admins probably leave that untouched for years and new security relevant headers might not be included for signing at some point in future. So IMO it would make sense to add more fine graded MTA DKIM config options like: "include these headers for dkim signing only if present in message" and/or "use default header names except of these". By taking these things into account, emails of domains with strict DMARC policies are no longer munged on gnu lists. Best regards, Christian Schoenebeck ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Thu, Oct 10, 2019 at 10:41:50AM -0400, Konstantin Ryabitsev wrote: > Hi, all: > > I would like to propose a new (large) feature to patchwork with the goal to > make the process of submitting a patch easier for newbies and people > generally less familiar with patch-based development. This was discussed > previously on the workflows list: > https://lore.kernel.org/workflows/20190930202451.GA14403@pure.paranoia.local/ > > How I envision this would work: > > - user creates an account (which requires a mail confirmation) > - they choose a "submit patch" option from the menu > - the patch submission screen has a succession of screens: > > 1. a screen with a single field allowing a user to paste a URL to their > fork of the git repository. Once submitted, patchwork does a "git > ls-remote" to attempt to get a list of refs and to verify that this is > indeed a valid git repository s/valid git repository/valid git repository based on the kernel git tree/ Otherwise you might be sending out lots of emails for other projects :) > > 2. next screen asks the user to select the ref to work from using the > list obtained from the remote. Once submitted, patchwork performs a `git > clone --reference` to clone the repository locally using a local fork of > the same repo to minimize object transfer. This part requires that: > a. patchwork project is configured with a path to a local fork, > if this feature is enabled for a project > b. that fork is kept current via some mechanism outside of > patchwork (e.g. with grokmirror) > c. there is some sanity-checking during the clone process to > avoid abuse (e.g. a sane timeout, a tmpdir with limited size, etc > -- other suggestions welcome) > > 3. next screen asks the user to pick a starting commit from the log. > Once submitted, patchwork generates the patch from the commit provided > to the tip of the branch selected by the user earlier, > using git format-patch. > > 4. next screen asks the user to review the patch to make sure this is > what they want to submit. Once confirmed, patchwork performs two > admin-defined optional hooks: > > a. a hook to generate a list of cc's (e.g. get_maintainer.pl) > b. a sanity check hook (e.g. checkpatch.pl) I will note that many "first patch" submissions are checkpatch.pl cleanups for staging. When doing that, I require that they do "one logical change per patch", which means that many of the individual patches themselves will not be checkpatch.pl clean, because many lines have multiple issues with them (tabs, spaces, format, length, etc.) So other than that minor thing, sounds interesting. It's hard to determine just how difficult the whole "set up git and send a patch out" process is for people these days given the _huge_ numbers of new contributions we keep getting, and the numerous good tutorials we have created that spell out exactly how to do this. So you might be "solving" a problem that we don't really have. It's hard to tell :( > I know this is a pretty big RFE, and I would like to hear your thoughts > about this. If there is general agreement that this is doable/good idea, I > may be able to come up with funding for this development as part of the > overall tooling improvement proposal. The workflow seems sane, and matches what most people do today, with the exception that it "solves" the git send-email issue, right? Is that our biggest barrier? I would recommend interviewing some of the recent kernel mentor project and outreachy applicants first, to try to determine exactly what their problems, if any, were with our development process. If they say that this type of tool/workflow would have saved them hours of time and energy, then that's a great indication that we should try to do this. thanks, greg k-h ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH] parser: Unmangle From: headers that have been mangled for DMARC purposes
Hi, >> Neat. There was discussion on a similar issue recently in: >> >> >> https://public-inbox.org/git/305577c2-709a-b632-4056-658277117...@redhat.com/ >> >> where a possible solution was to get senders to use in-body From >> headers even when sending their own patches. > > I think that's a good idea. > >> >> This might provide an alternate solution (or vice versa). I kind of like >> this one better in that it doesn't require the sender to do anything >> differently (but it may be less robust, as it assumes the receiver >> reliably de-mangling). > > Yep, it's less robust - but OTOH there's always a long tail of users > stuck on old versions of git for whatever reason and having some logic > to detect DMARC munging may thus still be useful. I'm not sure this solution is correct. If I take a patch from Andrew, backport it, and send to the list, Andrew will be listed in the in-body From. However, he shouldn't be the sender from the Patchwork point of view: he shouldn't get the patch status notification emails - I should. We don't want to spam an original author if their patch is backported to several different releases, or picked up and resent in someone else's series, etc etc. So unless I've misunderstood something, we can't rely on the in-body from matching Patchwork's understanding of the sender. Regards, Daniel > > -- > Andrew Donnellan OzLabs, ADL Canberra > a...@linux.ibm.com IBM Australia Limited > > ___ > Patchwork mailing list > Patchwork@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/patchwork ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
