From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751677AbeAZLpV (ORCPT ); Fri, 26 Jan 2018 06:45:21 -0500 Received: from mail-wr0-f173.google.com ([209.85.128.173]:43658 "EHLO mail-wr0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751355AbeAZLpT (ORCPT ); Fri, 26 Jan 2018 06:45:19 -0500 X-Google-Smtp-Source: AH8x2271JJtHojmR4CXSZ6GmGm4dwyGF+urnmAjsBPrFZ+egat0qJADlnEkL6beH7m5CvxqdQFcZUA== Date: Fri, 26 Jan 2018 11:45:14 +0000 From: Lee Jones To: SF Markus Elfring Cc: kernel-janitors@vger.kernel.org, LKML , Lars =?iso-8859-1?Q?P=F6schel?= , Samuel Ortiz Subject: Re: mfd: Patch management? Message-ID: <20180126114514.dwhwwgcp4n6fayre@dell> References: <9c50fe6a-21cc-e49d-1b10-5d2457ed4e2a@users.sourceforge.net> <20180123125851.ysypf7375sjlgsc6@dell> <20180123130130.powyttapsx3djawx@dell> <20180123151419.prwq62c7gpsnpbx3@dell> <20180123163130.h6ygmzig7syafxbh@dell> <49873902-c947-468d-094a-4ac175850116@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49873902-c947-468d-094a-4ac175850116@users.sourceforge.net> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 26 Jan 2018, SF Markus Elfring wrote: Do not send private emails containing list related content. > > 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