linux-kernel - Re: mfd: Patch management?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180123163130.h6ygmzig7syafxbh@dell>
Date:   Tue, 23 Jan 2018 16:31:30 +0000
From:   Lee Jones <lee.jones@...aro.org>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     kernel-janitors@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Lars Pöschel <poeschel@...onage.de>,
        Samuel Ortiz <sameo@...ux.intel.com>
Subject: Re: mfd: Patch management?

On Tue, 23 Jan 2018, SF Markus Elfring wrote:

> > My preferred mailer (Mutt) re-orders replied-to mails by putting them
> > to the top of my Inbox.  At which point I have to re-navigate down to
> > the next patch to review.
> 
> How much does this tool influence the amount of update suggestions
> which you could handle easily and safely?

In the 5 years I've been doing this, this is the first time someone
has submitted in such a way as to cause an issue.

> > This is fine for most submissions, but you have fired ~30,
> > mostly individual patches at me.
> 
> This number could be appropriate. I tried to contribute hundreds
> of change possibilities for various software components.

Moving forward, my advice to you would be to collect grouped patches
on a number of topic branches, then send them out in batches, perhaps
every couple of weeks.

Sending ~30 patches individually, spaced over a few hours/days, is
actually not a good system.  It is in fact quite inappropriate and a
pain to manage.  I for one find many (to be fair, very trivial)
patches scatter-gunned throughout my inbox to be rather inconvenient.

What I should do really is ask you to take all similar (remove error
message, don't use sizeof(struct X), remove '== NULL') changes and
squash them into single patches.  However, I realise that you might
want the "upstream creds", so I won't do that -- but not at the
expense of my time/effort.

The two choices are to squash or to create a set.

> > I'd like you to do the following please:
> 
> It will take a while until you might get the next chance to take
> another look at these subsequent patches.

I'm not in a hurry.

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog