Re: [RFC] Unify KVM kernel-space and user-space code into a singleproject

[Zachary Amsden]

On 03/18/2010 11:15 AM, Ingo Molnar wrote:
> * Zachary Amsden<zamsden@xxxxxxxxxx>  wrote:
>
>    
> > On 03/18/2010 12:50 AM, Ingo Molnar wrote:
> >      
> > > * Avi Kivity<avi@xxxxxxxxxx>   wrote:
> > >
> > >        
> > > > > The moment any change (be it as trivial as fixing a GUI detail or as
> > > > > complex as a new feature) involves two or more packages, development speed
> > > > > slows down to a crawl - while the complexity of the change might be very
> > > > > low!
> > > > >            
> > > > Why is that?
> > > >          
> > > It's very simple: because the contribution latencies and overhead compound,
> > > almost inevitably.
> > >
> > > If you ever tried to implement a combo GCC+glibc+kernel feature you'll know
> > > ...
> > >
> > > Even with the best-run projects in existence it takes forever and is very
> > > painful - and here i talk about first hand experience over many years.
> > >        
> > Ingo, what you miss is that this is not a bad thing.  Fact of the
> > matter is, it's not just painful, it downright sucks.
> >      
> Our experience is the opposite, and we tried both variants and report about
> our experience with both models honestly.
>
> You only have experience about one variant - the one you advocate.
>
> See the assymetry?
>
>    
> > This is actually a Good Thing (tm).  It means you have to get your
> > feature and its interfaces well defined and able to version forwards
> > and backwards independently from each other.  And that introduces
> > some complexity and time and testing, but in the end it's what you
> > want.  You don't introduce a requirement to have the feature, but
> > take advantage of it if it is there.
> >
> > It may take everyone else a couple years to upgrade the compilers,
> > tools, libraries and kernel, and by that time any bugs introduced by
> > interacting with this feature will have been ironed out and their
> > patterns well known.
> >      
> Sorry, but this is pain not true. The 2.4->2.6 kernel cycle debacle has taught
> us that waiting long to 'iron out' the details has the following effects:
>
>   - developer pain
>   - user pain
>   - distro pain
>   - disconnect
>   - loss of developers, testers and users
>   - grave bugs discovered months (years ...) down the line
>   - untested features
>   - developer exhaustion
>
> It didnt work, trust me - and i've been around long enough to have suffered
> through the whole 2.5.x misery. Some of our worst ABIs come from that cycle as
> well.
>    

You're talking about a single project and comparing it to my argument 
about multiple independent projects.  In that case, I see no point in 
the discussion.  If you want to win the argument by strawman, you are 
welcome to do so.

> Sorry, but i really think you are really trying to rationalize a disadvantage
> here ...
>    

This could very well be true, but until someone comes forward with 
compelling numbers (as in, developers committed to working on the 
project, number of patches and total amount of code contribution), there 
is no point in having an argument, there really isn't anything to 
discuss other than opinion.  My opinion is you need a really strong 
justification to have a successful fork and I don't see that justification.

Zach
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/