RFE: use patchwork to submit a patch

[Laurent Pinchart]

On Tue, Oct 15, 2019 at 11:11:57AM +0200, Dmitry Vyukov wrote:
> On Tue, Oct 15, 2019 at 10:57 AM Eric Wong wrote:
> > Dmitry Vyukov wrote:
> >> As one data point, I cannot send emails with git send-email anymore.
> >> It used to work, then broke and I don't know how to fix it. Now it says:
> >>
> >> 5.7.8 Username and Password not accepted. Learn more at
> >> 5.7.8  https://support.google.com/mail/?p=BadCredentials
> >> s10sm8376885wrr.5 - gsmtp
> >>
> >> I suspect it has something to do with two factor auth.
> >> So that's it: it cannot contribute to kernel right now.
> >> I will not consider time spent fixing it as useful time investment.
> >
> > I'm sorry you feel that way about time investments...
> > But I've always assumed that's also the sentiment for time spent
> > learning ANY new tools or workflow changes that come along.
> 
> This is true. But the fact that there is a learning curve to anything
> does not justify any learning curve for everything. Some parts of
> technology may be isolated completely and one does not need to learn
> anything about that part. For example, today to compile a high-level
> language one generally does not need to learn anything about machine
> instructions.

That's only true to some extent. Yes, you can develop in java without
knowing what a CPU is, but to develop efficient and safe software, a
knowledge of the whole stack is very useful, when not required.

> So the question is: is SMTP/IMAP is something that
> inherently needs to be learned for contribution to kernel or it can be
> hidden/not required/made simpler? And looking at github/facebook I
> would assume that contributors do not have to be exposed to that.

Could we develop a patch submission and review based on facebook if we
wanted to ? Most likely yes. Would we consider that as a good idea ?
Most likely no. There are always pros and cons in any workflow, and
while I could personally move away from e-mail, I would want a solution
that brings me most of the benefits of e-mail, in particular
decentralisation. git**b creates both a central point of failure and a
central point of trust, so it's a big no-go as far as I'm concerned. On
the other hand, creating a solution that enables optional use of forges
for contributors would prefer using them doesn't bother me at all, quite
the contrary.

> >> Any kernel documentation that I can find for gmail, mentions config
> >> that I am already using and that is not working:
> >> https://www.kernel.org/doc/html/latest/search.html?q=gmail&check_keywords=yes&area=default#
> >> https://www.kernel.org/doc/html/latest/process/email-clients.html?highlight=gmail
> >
> > Fwiw, git-send-email(1) manpage also has a special section for gmail:
> >
> >   https://kernel.org/pub/software/scm/git/docs/git-send-email.html
> >
> > and a link for app-specific passwords:
> >
> >   https://security.google.com/settings/security/apppasswords
> >
> > Perhaps that helps?
> 
> For me that page says "The setting you are looking for is not
> available for your account".
> I suspect app passwords work if 2-factor auth is enabled, but what
> enabled on my account is "Use your phone to sign in", which is
> different from 2-factor auth setting.

Did git-send-email start failing when enabling phone as a mean to sign
in, or was it unrelated ?

-- 
Regards,

Laurent Pinchart