Horst von Brand wrote:
> FORT David <[EMAIL PROTECTED]> said:
> > Horst von Brand wrote:
>
> [...]
>
> > > Dream on, as it won't happen. Just think of either:
> > >
> > > - All pieces _have_ to be the same version: What is the use then? Just ship
> > > them together and be done. Splitting it
On Tue, Oct 17, 2000 at 06:13:34PM -0600, Jeff V. Merkey wrote:
> Kenneth Johansson wrote:
> > "Jeff V. Merkey" wrote:
> > > 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
Stephen Tweedie wrote:
>
> Hi,
>
> On Tue, Oct 17, 2000 at 03:57:52PM -0600, Jeff V. Merkey wrote:
> >
> > 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.
>
FORT David <[EMAIL PROTECTED]> said:
> Horst von Brand wrote:
[...]
> > Dream on, as it won't happen. Just think of either:
> >
> > - All pieces _have_ to be the same version: What is the use then? Just ship
> > them together and be done. Splitting it up is extra work, plus the
> >
Hi,
On Tue, Oct 17, 2000 at 03:57:52PM -0600, Jeff V. Merkey wrote:
>
> 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.
Most of the big 2.4 module changes
Horst von Brand wrote:
> FORT David <[EMAIL PROTECTED]> said:
>
> > I totally agree, I'm really wondering if the current API would allow to
> > create a tree which would contain only files needed on
> > machine. Typically i never use sparc or mips file in kernel
> > compilation. I'm dreaming
FORT David <[EMAIL PROTECTED]> said:
> I totally agree, I'm really wondering if the current API would allow to
> create a tree which would contain only files needed on
> machine. Typically i never use sparc or mips file in kernel
> compilation. I'm dreaming of a day when i could download
FORT David [EMAIL PROTECTED] said:
I totally agree, I'm really wondering if the current API would allow to
create a tree which would contain only files needed on
machine. Typically i never use sparc or mips file in kernel
compilation. I'm dreaming of a day when i could download these
Hi,
On Tue, Oct 17, 2000 at 03:57:52PM -0600, Jeff V. Merkey wrote:
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.
Most of the big 2.4 module changes involved
FORT David [EMAIL PROTECTED] said:
Horst von Brand wrote:
[...]
Dream on, as it won't happen. Just think of either:
- All pieces _have_ to be the same version: What is the use then? Just ship
them together and be done. Splitting it up is extra work, plus the
complaints that
Stephen Tweedie wrote:
Hi,
On Tue, Oct 17, 2000 at 03:57:52PM -0600, Jeff V. Merkey wrote:
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.
Most of the
On Tue, Oct 17, 2000 at 06:13:34PM -0600, Jeff V. Merkey wrote:
Kenneth Johansson wrote:
"Jeff V. Merkey" wrote:
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
Let's see if Linus creates a modular 2.5 tree. If he does, merging
MANOS back into Linux will be a pleasant experience
Jeff
FORT David wrote:
>
> "Jeff V. Merkey" wrote:
>
> > Kenneth Johansson wrote:
> > >
> > > "Jeff V. Merkey" wrote:
> > >
> > > > Alan,
> > > >
> > > > Were Linux to
"Jeff V. Merkey" wrote:
> Kenneth Johansson wrote:
> >
> > "Jeff V. Merkey" wrote:
> >
> > > Alan,
> > >
> > > Were Linux to go totally modular in 2.5, development cycles will be
>
> > changes creap into the kernel that increase the time to a stable version. Making
> > the TODO list before
Kenneth Johansson wrote:
>
> "Jeff V. Merkey" wrote:
>
> > 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
> >
"Jeff V. Merkey" wrote:
> 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
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
> 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
What about creating three kernel series:
2.2. stable
2.4. feature frozen
2.5 development?
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.
Mirko
What about creating three kernel series:
2.2. stable
2.4. feature frozen
2.5 development?
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.
Mirko
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
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
"Jeff V. Merkey" wrote:
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
Kenneth Johansson wrote:
"Jeff V. Merkey" wrote:
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
"Jeff V. Merkey" wrote:
Kenneth Johansson wrote:
"Jeff V. Merkey" wrote:
Alan,
Were Linux to go totally modular in 2.5, development cycles will be
changes creap into the kernel that increase the time to a stable version. Making
the TODO list before instead of at the end
Let's see if Linus creates a modular 2.5 tree. If he does, merging
MANOS back into Linux will be a pleasant experience
Jeff
FORT David wrote:
"Jeff V. Merkey" wrote:
Kenneth Johansson wrote:
"Jeff V. Merkey" wrote:
Alan,
Were Linux to go totally modular in 2.5,
26 matches
Mail list logo
