[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140423181350.GE12304@sirena.org.uk>
Date: Wed, 23 Apr 2014 19:13:50 +0100
From: Mark Brown <broonie@...nel.org>
To: Lee Jones <lee.jones@...aro.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] regulator: First pull of MFD <-> Regulator IB (v3.16)
On Wed, Apr 23, 2014 at 04:00:47PM +0100, Lee Jones wrote:
> > Can you drop the last one please, I've already applied it? I'd have
> > expected just the first two (or probably even just the second one). If
> > you need it in your tree just grab the branch (or I can tag it if you
> > like).
> > I tend to apply these things early where they don't have dependencies
> > due to the large number of reposts for unrelated changes in the series
> > that tend to happen (and often several very similar serieses being in
> > flight at once); I frequently end up just deleting them unread. Not
> > sure what the best way to handle this stuff is in general.
> I know that you due, which I think makes things easier for you, but
> more difficult for everyone else (author, other maintainers). Applying
> cross-subsystem patches also makes things difficult down the line.
It's not really my convenience here - it's about trying progress the
serieses and cut the amount of code that people are having to carry.
People were complaining about things getting stalled due to lack of
review but of course one of the reasons for that is that it seems that
the early bits of the series commonly need respins and there's frequent
delays too (probably compounded by the frequent respins). That creates
a sense that these things are going nowhere slowly (or are just reposts
of already reviewed changes) which discourages spending time on them
until someone actively chases and then compounds the problem.
> Not sure what do do about the last patch now, as it has MFD changes
> which aren't in the MFD tree. All well and good if no one else touches
> that hunk for the remainder of the cycle, but if they do we're likely
> to have merge conflicts.
As I said above just pull the branch into MFD - like I say I can tag it
if you want, in fact I just pushed one:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/tps65090-reg-pdata-v3.16
That's what all the tiny topic branches are for, to make it easy to do
merges when needed - there shouldn't be any great difficulty here?
> > > Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++++
> > > drivers/mfd/tps65090.c | 41 +++++++++++++++++++++++++----------------
> > > drivers/power/tps65090-charger.c | 11 -----------
> > > drivers/regulator/tps65090-regulator.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > include/linux/mfd/tps65090.h | 19 +++++++++++++++++++
> > > 5 files changed, 104 insertions(+), 27 deletions(-)
> > Your formatting for these still seems to be messing up.
> How so? Looks fine for me I think?
The lines are *way* over 80 columns, look to be formatted for about 130
or something.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists