On Thu, 2019-10-10 at 10:41 -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/
I'll echo Daniel's sentiments that I like the idea of a git-to-email bridge, but that I'm not sure if that should belong in Patchwork core. I too am open to being convinced but before we get to anything like a solution though, I'd like to identify the problem(s) you're trying to solve. From reading this thread, it seems there are three separate issues issues intertwined here. * Corporate email is often broken, meaning people have to jump through hoops to simply submit a patch, if it's even possible. [1] * Encoding metadata in emails has to be done in an ad-hoc, freeform fashion, through special headers, tags in the subject or specific annotations in the body. This requires reading large contributors guides before sending anything. * Using CLI tools in general is hard for newbies (?) Asssuming those are correct, I'd like to challenge some of them :) There isn't a whole lot that can be done about broken email, at least until JMAP becomes a thing (it's done over HTTP so that could help. Or not. idk), but I'm not sure about the other two. I don't know what kind of metadata would be needed to submit a patch to a random subtree of the kernel, but I assume the metadata exists for a reason? If so, is this actually something we can tackle via a UI or CLI without producing custom workflow tools for every single project and if not, can we actually solve this particular issue? Personal, I would consider reading the contributor guide a minimum barrier to entry, as without this you're simply transferring work from contributors to (often overworked) maintainers but I do acknowledge that it's easy for me to say that since I know how to do this stuff already. The same idea applies to the idea of not using CLIs. Is there an statistically significant amount of people that would be able to submit useful changes but can't use a CLI tool? I know you can get away without using a terminal for traditional Windows development or web development, but surely terminal knowledge is a prerequisite for almost everything else? What I'm trying to get at here is figure out if (a) this is something that can really benefit from living in Patchwork, (b) this is something that needs a UI, (c) this is something's that necessary full stop (vs. just waiting for projects to switch to GitLab or Gerrit or whatever new cool ends up being). If we can figure that out, we can look into how we can go about implementing stuff. Stephen [1] I've multiple personal examples of this, from having to ask IT during my Intel days to remove automatic legal signatures to outlook.com refusing to respect message-id's, resulting in broken threading at a minimum. Thankfully I don't have to jump through those hoops at Red Hat but yeah, eew. _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
