On Sat, 22 Oct 2005, Stefan Richter wrote:
> Christoph Hellwig wrote:
>> On Sat, Oct 22, 2005 at 12:42:27PM +0200, Stefan Richter wrote:
>>> A. Post mock-ups and pseudo code about how to change the core, discuss.
>>> B. Set up a scsi-cleanup tree. In this tree,
>>> 1. renovate the core (thereby break all command set drivers and
>>> all transport subsystems),
>>
>> No way. Doing things from scatch is a really bad idea. See how far we
>> came
>> with Linux 2.6 scsi vs 2.4 scsi without throwing everything away and break
>> the
>> world. Please submit changes to fix _one_ thing at a time and fix all
>> users.
>> Repeat until done or you don't care anymore.
>
> I agree with you. Alas my wording was misunderstandable und obviously carried
> a wrong tone.
>
> I did not say "replace the core" in step 1. Also, the breakage which I refer
> to in step 1 would have to be immediately corrected in step 2 (although not
> for the whole subsystem at once, to allow for a fast cycle of validation of
> what happened in step 1). Furthermore I specifically said that most steps may
> (let me add: and should) overlap.
Stefan,
we are supposed to be on a 2-month release cycle, with all major changes
going in in the first two weeks of that cycle. This timeframe doesn't
leave you any noticable time to implement your steps seperatly (and zero
testing between them). as a result, in practice your proposal amounts to a
big-bang approach, and/or results in releases that are known-broken.
and while you suggest putting this in -mm, remember that the -mm kernel
needs to be useable so that people can test it, and it is on the same
schedule as the main kernel so again you can't have known-broken things
(of this scale) there either.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
David Lang wrote:
> Stefan,
> we are supposed to be on a 2-month release cycle, with all major
> changes going in in the first two weeks of that cycle. This timeframe
> doesn't leave you any noticable time to implement your steps seperatly
> (and zero testing between them). as a result, in practice your proposal
> amounts to a big-bang approach, and/or results in releases that are
> known-broken.
Experimental branches of subsystems usually cannot (nor need to) be
bound to a release cycle.
> and while you suggest putting this in -mm, remember that the -mm kernel
> needs to be useable so that people can test it, and it is on the same
> schedule as the main kernel so again you can't have known-broken things
> (of this scale) there either.
I assumed there would be a few unmaintained bits (of marginal "scale")
left which could not be updated, but it seems now that won't be the
case.
--
Stefan Richter
-=====-=-=-= =-=- ==--=
http://arcgraph.de/sr/