On Sat, Oct 12, 2019 at 09:19:11AM +0200, Greg KH wrote:
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)
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?
The magic of git and email headers. Only the initial submission will go
out of this web service -- the follow-up is expected to arrive into
their mailbox.
2. use individual git feeds as a way to send out patches instead of always
being secondary to SMTP
Sending patches that way is one thing, the interaction based on those
patches is another.
Everyone needs to remember that only 1/3 of the patches submitted are
applied. The "normal" path of development is at least a review/resend
cycle for submissions (2/3 of patches). So that 2/3 can't be ignored as
the "new/drive-by submissions" are probably more in that category than
not.
Right, the idea is that the imaginary tool that is backed by
public-inbox will use multiple sources of content:
- the mailing list repository
- individual developer feeds
- the person's imap folder
Anything that shows up in the individual feeds should have a
corresponding entry in the mailing list repository, but the latter is
also cryptographically signed and therefore end-to-end attestable.
Mailing lists and SMTP continue to be the fallback delivery method for
the vast majority of the content.
I expect to lay this out in more detail as I prepare the "kthul MVP"
roadplan.
-K
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
