Re: [GIT PULL] SCSI fixes for 2.6.32-rc3

[Ingo Molnar <mingo@elte.hu>]

* James Bottomley <James.Bottomley@suse.de> wrote:

> > > To me, the matter of staging versus actual tree isn't a quality 
> > > issue (otherwise we'd be shifting ~75% of SCSI drivers to staging, 
> > > depending on whose view of "quality" was being used). [...]
> > 
> > I think you need to update your notion of what goes into 
> > drivers/staging/ - these days it's primarily about 
> > code/implementation quality (Greg please correct me if i'm wrong 
> > about that).
> > 
> > Driver ABIs are distinctly down the priority list.
> 
> Not for me they're not.  We worked hard to unify exposed ABIs for 
> drivers, so this is the most important user visible feature.  We can 
> clean up code in the drivers tree, that's easy.  We can't break the 
> user visible ABI of a supported driver without causing a lot of pain 
> to its user community.

I think you are interpreting what should go into drivers/staging/ _very_ 
narrowly.

Basically if you skip the drivers/staging/ step for unclean drivers you 
_remove_ an incentive of driver authors to fix up crap. If it's upstream 
already without cleanups then why bother cleaning it up fully?

Staging should be for drivers that arent clean enough for mainline as-is 
(having a messy ABI can be one of the reasons that makes a driver 
unclean), but which are still important enough and have active 
maintainers/developers who care about them.

It's basically an optimistic multi-step trust algorithm for drivers 
whose lack would otherwise be a "cannot use upstream" showstopper for a 
significant class of Linux users - but which are not yet clean enough 
for upstream inclusion. The 4 steps of:

 - out of tree
 - in Greg's staging tree
 - upstream in drivers/staging/
 - upstream in drivers/

Offer various degrees of incentives and walking that path expresses it 
both to driver authors and to kernel maintainers that all parties 
involved can be trusted to produce clean code.

Everyone wins from that:

 - users get faster hw-enablement

 - driver authors get reinforcement that their stuff is moving forward 
   (which they can communicate back to their employers)

 - maintainers get patches that they can build trust upon and the danger 
   of release-and-forget drivers is lessened.

 - even if authors orphan a driver, actual real users have the ability 
   to move things themselves.

 - [ if none of that happens then sure the driver wasnt all that 
     important to begin with and can be dropped - nobody loses. ]

I think your interpretation is arbitrary - where did you get that ABI 
rule from? I'm sure it cannot be from any of the drivers/staging/ 
discussions on lkml, i've followed them quite closely. If 'has a messy 
ABI' was the only requirement for drivers/staging/ then we could move 
90% of drivers/staging/ into drivers/ straight away - and that would be 
counter-productive IMHO.

Sidenote, in fact i think we should expand on that: drivers/staging/ 
should be used in the _other_ direction as well - to un-upstream stale 
drivers that are abandoned and unused, in a gradual fashion. 'git mv' is 
cheap.

Basically, drivers/staging/ gives us an excellent opportunity to 
_increase_ the quality of drivers by applying stronger upstream 
inclusion filters, without having to hurt users/developers in the 
process. We just have to start using it that way as well.

	Ingo