Re: mfd: Patch management?

[Lee Jones <lee.jones@linaro.org>]

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