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>] [day] [month] [year] [list]

Date:   Fri, 26 Jan 2018 11:45:14 +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 Fri, 26 Jan 2018, SF Markus Elfring wrote:

Do not send private emails containing list related content.

<putting this conversation back on the list, where it belongs>

> > Moving forward, my advice to you would be to collect grouped patches
> > on a number of topic branches,
> 
> I am using development branches generally.

Great, so write patches and add them to your topic branches.  Then
send them out periodically, together, as a threaded set.

  See: `git send-email` -- grep for "--thread"

> > then send them out in batches, perhaps every couple of weeks.
> 
> I got other preferences for time ranges around patch distribution.

Not sure what this means.  I'm guessing you're saying that you are not
willing to collect your patches and you intend on sending them one at
a time, over time.

If I am understanding you correctly, then your patches will not be
reviewed.

> > Sending ~30 patches individually, spaced over a few hours/days,
> > is actually not a good system.
> 
> It happened that several update candidates were noticed by static
> source code analysis also in this software area.

Doesn't matter.  Collect them up and send them as a batch.

> > It is in fact quite inappropriate and a pain to manage.
> 
> It becomes more interesting when the patch numbers grow, doesn't it?

When contributors do not manage their submissions properly, it does
become more *annoying* and unmanageable, yes.

> > I for one find many (to be fair, very trivial) patches scatter-gunned
> > throughout my inbox to be rather inconvenient.
> 
> Are you looking for any better management tools?

No.

> Do you find any of the remaining change possibilities acceptable
> in principle?

I'm not going to review them until you re-submit them in an acceptable
manner, as requested.

> > The two choices are to squash or to create a set.
> 
> When will the adjustments which you could integrate already
> appear on the Linux next interface?
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/mfd/

When the merge-window closes.

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