Alan,
Were Linux to go totally modular in 2.5, development cycles will be
reduced by 1/2 to 1/3. This is because you could always roll back to
known good modules to post a release. The way you guys are going, if
Linux stays monolithic, your cycles will get longer and longer.
Modularity will allow multiple people to proceed in parallel without
every patch and bug going through you and Linus all the time (which
would mean you could enjoy more free time).
This does not solve the problem of integration testing, but eh solution
here is to create an integration test group whose sole charter is to
test modules in an integrated framework as they roll off the assembly
line. I am speaking from my commercial software development experienes
here. Linux is falling into the same rut NetWare did as it became
successful -- too much work for mere mortals without some new structures
put in place.
Just a thought.
:-)
Jeff
Alan Cox wrote:
>
> > As soon as 2.4 comes out, 2.7 is created, 2.6test
> > will be feature frozen.
> > Development time would be shorter, and
> > the nuisance with "this important feature has tz slip
> > in" would be finished.
>
> It requires too much people overhead. I have proposed another idea which is at
> about 10 months in or when seems appropriate we say 'ok which bits can we
> fairly reliably backport to 2.4 and call 2.6' then go on to make 2.5->2.7 and
> stabilise the big changes as 2.8
>
> That would mean driver features and the like get a yearly cycle but deep magic
> gets what seems to be needed as a 2 year cycle
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
