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
On Fri, Nov 08, 2019 at 03:25:00PM +0100, Dmitry Vyukov wrote:
> > Would you like a mail sending account so you can use mail.kernel.org
> > as
> > your outgoing smtp? We promise we won't do anything that nasty. :)
> >
> > -K
>
> You know that we also serve Fuchsia, Akaros, FreeBSD, NetBSD,
On Mon, Nov 11, 2019 at 10:35:10AM +0100, Dmitry Vyukov wrote:
>
> 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
On Fri, Nov 08, 2019 at 03:25:00PM +0100, Dmitry Vyukov wrote:
>
> It has the format=flowed; delsp=yes part:
>
> Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes
>
> Which according to https://tools.ietf.org/html/rfc3676 seems to mean
> that that line is not wrapped: new line
Hi Ted,
On Fri, Nov 08, 2019 at 09:02:49AM -0500, Theodore Y. Ts'o wrote:
> On Fri, Nov 08, 2019 at 10:44:25AM +0100, Dmitry Vyukov wrote:
> > syzbot asks to provide fixing commit in a particular format (and on 1
> > line, otherwise not possible to parse back).
> >
> > It sent this yesterday:
>
On Fri, Nov 08, 2019 at 03:12:51PM +0100, Dmitry Vyukov wrote:
> Just to clarify: syzbot does not do this on purpose. It generates and
> hands off unwrapped lines. The "format=flowed; delsp=yes" part was
> done by somebody else.
Looks like vger received it already mangled:
On Thu, Oct 24, 2019 at 3:58 PM Steven Rostedt wrote:
>
> On Thu, 24 Oct 2019 15:33:04 +0200
> Dmitry Vyukov wrote:
>
> > On Thu, Oct 24, 2019 at 3:15 PM Steven Rostedt wrote:
> > >
> > > On Mon, 21 Oct 2019 18:39:18 +0300
> > > Laurent Pinchart wrote:
> >
> > Purely theoretically let's
On Thu, 24 Oct 2019 15:33:04 +0200
Dmitry Vyukov wrote:
> On Thu, Oct 24, 2019 at 3:15 PM Steven Rostedt wrote:
> >
> > On Mon, 21 Oct 2019 18:39:18 +0300
> > Laurent Pinchart wrote:
>
> Purely theoretically let's consider that the changes do not improve
> _your_ efficiency, but they
On Thu, Oct 24, 2019 at 3:15 PM Steven Rostedt wrote:
>
> On Mon, 21 Oct 2019 18:39:18 +0300
> Laurent Pinchart wrote:
>
> > > I plan on continuing to develop mostly in email (I still send my patch
> > > series via quilt!). But I'm not going to enforce everyone to continue
> > > to use email if
On Mon, 21 Oct 2019 18:39:18 +0300
Laurent Pinchart wrote:
> > I plan on continuing to develop mostly in email (I still send my patch
> > series via quilt!). But I'm not going to enforce everyone to continue
> > to use email if we can come up with a better way. I also want to make
> > sure that
Hi Steven,
On Tue, Oct 15, 2019 at 12:47:49PM -0400, Steven Rostedt wrote:
> On Tue, 15 Oct 2019 19:37:04 +0300 Laurent Pinchart wrote:
>
> > But how far could we push this reasoning ? I've worked for a company
> > whose corporate policy was that all source code had to be stored in SVN,
> > not
On Tue Oct 15, 2019 at 7:44 PM Laurent Pinchart wrote:
> I'm not very confident that perfect transparent e-mail bridges could be
> developed, and the culprit here it e-mail. From forge to e-mail there's
> no real issue, we have structure data, and we write it out in text form.
> The other way
On Tue, 15 Oct 2019 19:37:04 +0300
Laurent Pinchart wrote:
> But how far could we push this reasoning ? I've worked for a company
> whose corporate policy was that all source code had to be stored in SVN,
> not exception. I didn't reach the community to move kernel development
> away from git.
On Tue, Oct 15, 2019 at 06:41:03AM +0200, Dmitry Vyukov wrote:
> On Mon, Oct 14, 2019 at 5:17 PM Greg KH 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
On Tue, Oct 15, 2019 at 07:32:41PM +0300, Laurent Pinchart wrote:
Well, this is largely what GitGitGadget does
(https://gitgitgadget.github.io), and we could go that route, sure. I'm
reluctant only because, quoth:
GitGitGadget itself is a GitHub App that is backed by an Azure
Function
Hi Drew,
On Tue, Oct 15, 2019 at 12:34:57PM -0400, Drew DeVault wrote:
> On Tue Oct 15, 2019 at 7:32 PM Laurent Pinchart wrote:
> > I certainly wouldn't recommend a solution based on a proprietary
> > closed-source stack :-) But as we're talking about performing new
> > development for patchwork,
Hi Steven,
On Tue, Oct 15, 2019 at 08:37:41AM -0400, Steven Rostedt wrote:
> On Mon, 14 Oct 2019 16:56:58 -0400 "Theodore Y. Ts'o" wrote:
>
> > So it's an extreme case, and is an example of corp e-mail insanity.
> > The good news is that for companies that are really serious about
> > working
Hi Konstantin,
On Tue, Oct 15, 2019 at 11:40:10AM -0400, Konstantin Ryabitsev wrote:
> On Mon, Oct 14, 2019 at 06:33:33PM +0300, Laurent Pinchart wrote:
> > If the goal is to work around SMTP-related technical issues, is a web UI
> > really the best way to go ? Wouldn't it be better to do the
Hi Dmitry,
On Tue, Oct 15, 2019 at 06:49:27AM +0200, Dmitry Vyukov wrote:
> On Mon, Oct 14, 2019 at 5:12 PM Laurent Pinchart wrote:
> > On Mon, Oct 14, 2019 at 04:58:17PM +0200, Dmitry Vyukov wrote:
> >> On Fri, Oct 11, 2019 at 7:20 PM Shuah Khan wrote:
> >>> On 10/11/19 2:57 AM, Greg KH wrote:
>
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:
> >>
>
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
On Tue, Oct 15, 2019 at 09:35:27AM -0400, Theodore Y. Ts'o wrote:
On Tue, Oct 15, 2019 at 08:37:41AM -0400, Steven Rostedt wrote:
Now, if we had a way to send and receive upstream patches via a web
site, that would actually make things easier.
Alas, for those corporations who choose to enable
On Tue, Oct 15, 2019 at 08:37:41AM -0400, Steven Rostedt wrote:
> Now, if we had a way to send and receive upstream patches via a web
> site, that would actually make things easier.
Alas, for those corporations who choose to enable DMARC in hard-fail
mode (which includes google.com BTW, although
On Mon, 14 Oct 2019 16:56:58 -0400
"Theodore Y. Ts'o" wrote:
> So it's an extreme case, and is an example of corp e-mail insanity.
> The good news is that for companies that are really serious about
> working with upstream, they will roll out solutions for their own
> customers. For example,
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
>
On Mon, Oct 14, 2019 at 11:28:59AM -0300, Mauro Carvalho Chehab wrote:
Yeah, our current security model is based at the maintainer for
him to do his duties, properly reviewing the patch.
Yet, at the example that Daniel gave:
Instead of:
if ((permissions == allowed) && other_stuff) {
On Mon, 14 Oct 2019 10:38:51 +1100
Daniel Axtens wrote:
> > It does bring up that any new workflow has to have security protocol
> > and threat model as part of its design.
>
> This is actually something that worries me about the patchwork
> workflow. Maintainers seem to trust the patchwork
Em Mon, 14 Oct 2019 08:26:37 -0400
"Theodore Y. Ts'o" escreveu:
> On Mon, Oct 14, 2019 at 12:42:36PM +0200, Toke Høiland-Jørgensen wrote:
> > It should be detectable, though, right?
> >
> > Say you have two independently administered patchwork instances (or even
> > better, two different
Em Mon, 14 Oct 2019 09:53:58 -0400
"Theodore Y. Ts'o" escreveu:
> On Mon, Oct 14, 2019 at 10:41:32AM -0300, Mauro Carvalho Chehab wrote:
> > It can still have man-in-the-middle (MITM) attacks between the sender and
> > vger.kernel.org. Please notice that using https and adding the patch
> > via
Hi Eric,
On Mon, Oct 14, 2019 at 2:12 AM Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > 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
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
Geert Uytterhoeven wrote:
> On Mon, Oct 14, 2019 at 2:12 AM Eric Wong wrote:
> > We can also find creative ways to subvert corporate policies:
> > For example; if their policy specifically prevents outgoing SMTP,
> > "git imap-send" could be used.
>
> IMAP may be blocked, too?
Yes, was just
On Mon, Oct 14, 2019 at 10:41:32AM -0300, Mauro Carvalho Chehab wrote:
> It can still have man-in-the-middle (MITM) attacks between the sender and
> vger.kernel.org. Please notice that using https and adding the patch
> via a web interface can also be subject to MITM, as companies and even some
>
"Theodore Y. Ts'o" writes:
> On Mon, Oct 14, 2019 at 12:42:36PM +0200, Toke Høiland-Jørgensen wrote:
>> It should be detectable, though, right?
>>
>> Say you have two independently administered patchwork instances (or even
>> better, two different software packages entirely) that both subscribe
On Mon, Oct 14, 2019 at 12:42:36PM +0200, Toke Høiland-Jørgensen wrote:
> It should be detectable, though, right?
>
> Say you have two independently administered patchwork instances (or even
> better, two different software packages entirely) that both subscribe to
> the mailing lists, and
Daniel Axtens writes:
>> It does bring up that any new workflow has to have security protocol
>> and threat model as part of its design.
>
> This is actually something that worries me about the patchwork
> workflow. Maintainers seem to trust the patchwork version of a patch
> without much (or
Konstantin Ryabitsev wrote:
> 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
On Mon, Oct 14, 2019 at 04:58:17PM +0200, 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
Hi Konstantin,
On Fri, Oct 11, 2019 at 05:35:53PM -0400, Konstantin Ryabitsev wrote:
> 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
Hi Greg,
On Mon, Oct 14, 2019 at 05:17:11PM +0200, Greg KH wrote:
> On Mon, Oct 14, 2019 at 04:58:17PM +0200, Dmitry Vyukov wrote:
> > On Fri, Oct 11, 2019 at 7:20 PM Shuah Khan wrote:
> > > On 10/11/19 2:57 AM, Greg KH wrote:
> > > > On Thu, Oct 10, 2019 at 10:41:50AM -0400, Konstantin Ryabitsev
Hi Dmitry,
On Mon, Oct 14, 2019 at 04:58:17PM +0200, Dmitry Vyukov wrote:
> On Fri, Oct 11, 2019 at 7:20 PM Shuah Khan wrote:
> > On 10/11/19 2:57 AM, Greg KH wrote:
> >> On Thu, Oct 10, 2019 at 10:41:50AM -0400, Konstantin Ryabitsev wrote:
> >>> Hi, all:
> >>>
> >>> I would like to propose a new
> It does bring up that any new workflow has to have security protocol
> and threat model as part of its design.
This is actually something that worries me about the patchwork
workflow. Maintainers seem to trust the patchwork version of a patch
without much (or any) verification that it matches
On Sat, 2019-10-12 at 14:16 +0100, Stephen Finucane wrote:
> 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
>
On Fri, Oct 11, 2019 at 04:02:28PM -0400, Konstantin Ryabitsev wrote:
> 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
On Fri, Oct 11, 2019 at 05:35:53PM -0400, Konstantin Ryabitsev wrote:
> 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
> > >
On Fri, 11 Oct 2019 17:08:39 -0700
Stephen Hemminger wrote:
> Yes, my life is too short to fight with corporate stuff.
Heh, me too.
> 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
On Sat, 12 Oct 2019 08:54:22 +1000
Dave Airlie wrote:
> On Sat, 12 Oct 2019 at 08:34, Steven Rostedt wrote:
> >
> > On Fri, 11 Oct 2019 14:19:09 -0700
> > Stephen Hemminger wrote:
> >
> > > As someone who has to deal with a corporate busted mail server.
> > > I agree mailing patches is a
> 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
I happen to have been working on something like this today:
https://sr.ht/x71F.png
This doesn't require any JavaScript.
I've also been working on the other side, but it's less shiny - I'm
teaching pygit2 about pluggable object db backends so that I can teach
my mailing lists to talk to my git
On Sat, 12 Oct 2019 at 08:34, Steven Rostedt wrote:
>
> On Fri, 11 Oct 2019 14:19:09 -0700
> Stephen Hemminger 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
Em Fri, 11 Oct 2019 11:32:54 -0700 (PDT)
David Miller escreveu:
> 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
On Fri, 11 Oct 2019 14:19:09 -0700
Stephen Hemminger 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
Em Fri, 11 Oct 2019 14:44:01 -0400
Steven Rostedt escreveu:
> On Fri, 11 Oct 2019 11:32:54 -0700 (PDT)
> David Miller wrote:
>
> > 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
Em Thu, 10 Oct 2019 15:53:35 -0400
Konstantin Ryabitsev escreveu:
> On Thu, Oct 10, 2019 at 03:07:29PM -0300, Mauro Carvalho Chehab wrote:
> >> - 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
Em Fri, 11 Oct 2019 11:20:17 -0600
Shuah Khan escreveu:
> On 10/11/19 2:57 AM, Greg KH wrote:
> > 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
On 10/11/19 2:57 AM, Greg KH wrote:
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
Konstantin Ryabitsev wrote:
> 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
On Fri, 11 Oct 2019 11:32:54 -0700 (PDT)
David Miller wrote:
> 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
On Fri, 11 Oct 2019 14:37:52 -0300
Mauro Carvalho Chehab wrote:
> I agree with Shuah. From time to time, we have one time only patch
> submission from people that just want to fix something that affects
> his machine.
I like to stress this point. There's been projects that I have written
a
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
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
> >
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
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
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
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
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
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
Jonathan Nieder wrote:
> Eric Wong wrote:
> > Konstantin Ryabitsev wrote:
>
> >> This is actually really fast if you already have a local copy of the
> >> repository with most objects. Try this yourself if you have
> >> torvalds/linux.git locally:
> >>
> >> git clone --bare -s
Konstantin Ryabitsev wrote:
> This is actually really fast if you already have a local copy of the
> repository with most objects. Try this yourself if you have
> torvalds/linux.git locally:
>
> git clone --bare -s torvalds/linux.git test
Yep, -s (--shared) makes cloning really cheap. One of
On Thu, 10 Oct 2019 15:07:29 -0300
Mauro Carvalho Chehab wrote:
> Em Thu, 10 Oct 2019 10:41:50 -0400
> Konstantin Ryabitsev escreveu:
>
> > 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
Em Thu, 10 Oct 2019 10:41:50 -0400
Konstantin Ryabitsev escreveu:
> 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
On Fri, Oct 11, 2019 at 08:38:49AM +1100, Daniel Axtens wrote:
Hi Konstantin,
tl;dr: I think a git-to-email bridge is a good step. I'm not sure why
patchwork would be the thing to build it on top of, and I'm worried that
it would slow us both down. I'm very open to being convinced though.
In
Hi Konstantin,
tl;dr: I think a git-to-email bridge is a good step. I'm not sure why
patchwork would be the thing to build it on top of, and I'm worried that
it would slow us both down. I'm very open to being convinced though.
> I would like to propose a new (large) feature to patchwork with the
Eric Wong wrote:
> Konstantin Ryabitsev wrote:
>> This is actually really fast if you already have a local copy of the
>> repository with most objects. Try this yourself if you have
>> torvalds/linux.git locally:
>>
>> git clone --bare -s torvalds/linux.git test
>
> Yep, -s (--shared) makes
(+cc: git)
Hi,
Konstantin Ryabitsev wrote[1]:
> 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:
Interesting! This reminds me a
On Thu, Oct 10, 2019 at 03:07:29PM -0300, Mauro Carvalho Chehab wrote:
- 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.
This will raise the bar, as it will force all developers
76 matches
Mail list logo
