Open Stack

On Wed, 2016-07-20 at 21:24 +0300, Duncan Thomas wrote:
> On 20 July 2016 at 19:57, James Bottomley <
> James.Bottomley at hansenpartnership.com> wrote:
> 
> > 
> > OK, I accept your analogy, even though I would view currency as the
> > will to create and push patches.
> > 
> > The problem you describe: getting the recipients to listen and
> > accept
> > your patches, is also a common one.  The first essential is simple
> > minimal patches because they're hard to reject.
> > 
> > Once you've overcome the reject barrier, there's the indifference
> > one
> > (no-one says no, but no-one says yes).
> > 
> > [snip]
> 
> The trouble with drive-by architecture patches (or large feature 
> patches of any kind)

OK, there's an assumption here: that the patch is large.

>  is that it is often better *not* to merge them if you don't think
> the contributor is  going to stick around for a while. This changes
> are usually intrusive, and have repercussions that take time to
> discover. It's often difficult to keep a change clean when the
> original author isn't around to review the follow-on work.

I understand (and do agree with) the Maintenance problem.  However, if
you're trying to change architecture, and you do it by small patches,
it looks easily reversible and is a lot easier to gain acceptance for. 
 The key is to think small not big (the latter being the temptation for
architecture) even if the end result will eventually be big.

Let me give you an example from ancient history.  The biggest
architectural change I pushed into Linux was switching from bus
specific to generic device APIs.  I did it at the time because I had a
SCSI device in the PA-RISC architecture that could sit on a variety of
internal busses and I didn't want a huge driver with five sets of
partially duplicated code for five different busses.

Here's the first patch (both dated 21 Dec 2002)

    generic device DMA API

    27 files changed, 750 insertions(+), 155 deletions(-)

And the second

    allow pci primary busses to have parents in the device model

    2 files changed, 14 insertions(+), 5 deletions(-)

The first is large because I'm actually introducing yet another
parallel DMA API (50% of it is documentation).  It looks OK because all
our other DMA APIs were bus specific.

The second is the key change because it allows cascades of bus
hierarchies of different types.

These two patches are easy to gain acceptance for because they're just
introducing new APIs and not altering existing stuff.  They're small
and easily revertible if I happened to disappear (or they proved not to
work out in practice).  They were, however, enough to allow me to
convert the PA-RISC architecture to the new model and write the driver
I wanted for the 53c700 chip.

The end point we're at today, where practically every device API in
Linux uses generic devices, is no longer revertible.  If it were done
as one patch, it would touch about 80% of all the files in Linux and be
larger than the kernel itself.  However, I didn't do that: I pushed the
minimum viable patch set that would support what I wanted to do (plus
the use cases for a couple of other interested parties I picked up
along the way).

James