Status of arch/arm in linux-next

[Mark Brown]

On Mon, Apr 18, 2011 at 11:40:15PM +0200, Thomas Gleixner wrote:
> On Mon, 18 Apr 2011, Mark Brown wrote:

> > Yeah, I saw that.  Quite frankly it's astonishing - I must apologise, I
> > had thought you were most likely misinterpreting what he was saying.

> Sigh.

I find it hard to read it as saying anything other than that new code is
unwelcome and any substantial diffstat needs to be negative.  This is
pretty much what Russell has been saying (if a bit less hard line).

> > To make matters worse unless people just give up the longer we keep the
> > tree shut down the larger the merge will be when it does reopen.

> I tend to disagree. It's not rocket science to cleanup stuff just
> along the way. I did the (not yet perfect) conversion of about 20 irq
> chips on saturday just to see how far I get with that abstract
> chip. And it simply got rid of >1200 LOC with some more potential
> reduction already detected.

That's not terribly helpful to people trying to contribute anything
other than refactoring of existing code - the message that's been given
is that anything which adds new support (platforms, machines, whatever)
is not even worth looking at.  For people working on code that's already
in mainline they can refactor and that's fine for them.  If that's not
the case then people are just being told the code is not welcome until
some non-specific amount of cleanup work has been done to existing code.

This is not really constructive from the contributor side as it doesn't
offer any direct or clear route to addressing the problem that's
blocking their code, there's no improvement that can be made to code
that would make it worth considering.  What we're telling people to do
is work on random improvements to more or less tangentially related
code.  This doesn't seem entirely reasonable and is going to be
especially offputting for new contributors (like the people trying to
submit new platforms, many of them will be new to mainline work) as it's
a pretty big jump to start working on less familiar code when you're
still trying to find your feet and worried about stepping on people's
toes or breaking things, not to mention justifying your time to
management.

> So when we come up with such generic abstractions then it's not
> a too big burden for a maintainer to care about his 1 or 2 irq chips
> and some other small cleanups here and there.

Of course, it's obvious that as we add abstractions we'll be able to
make improvements.  Saying to people that they should use existing
abstractions (recently added or otherwise) or even that they should
factor out bits of their code so that others can use them is exactly the
approach I'd hope we'd be taking here.  That would be clear, relevant
review which gives people something direct they can work towards.

> Linus does not expect that ARM code shrinks 80% in the next cycle, but
> he wants to see that people take him seriously and actually cut down
> code in a diffstat visible way.

The issue for me is that we're doing that not by raising the bar on new
contributions and demonstrating that there's work going into factoring
stuff out but rather by shutting down entirely to pretty much anything
other than refactoring so that we force a negative diffstat.

It'd be much better if we could do something like what Grant suggested
earlier in the thread, splitting out the refactoring work (which you'd
hope will have a nice looking diffstat) from the run of the mill stuff
so that the cleanup is highlighted, especially when we combine this
approach with the more stringent review that pretty much everyone is
bought in to.  That seems more sustainable for the long term, and much
more helpful for ongoing development.