lkml.org 
[lkml]   [1996]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: A Humble Suggestion for 2.0/2.1 (fwd)
Date
On Wed, 19 Jun 1996, hab wrote:

> Jim Nance wrote:
> > (I wrote:)
> > > Next time, I think it would be a good thing if we (Hi, Linus!) were to
> >
> > From the standpoint of software developers (I am one), the longer between
> > kernels the better. Of course this does have to be balanced against peoples
> > need for new hardware support and new features.

Ok, I can see this. Massive rewriting of the network internals might not
have been a good thing to put into 1.2.14. AHA2940 support would have.

> There is a balancing act that needs to go on here, and I think Linus does try

Agreed on both counts. 8^)

> to
> observe about a year between releases

If your lines weren't so long, I wouldn't have to chop; them.

> as evidenced by his attempts to try and
> freeze the kernel much earlier than when it was accomplished.

Perhaps a distinction, as has already been proposed, between driver
updates and major releases would be helpful in this discussion. So
agreed.

Within the overall context of kernel development, I think the rate of
progress is breathtaking and acceptable. A year between major releases
is fine, but I still think we could release incremental stable kernels
more regularly. More below.

> However, there are
> still features that get developed independent of schedule that cry for
> release.

Indeed.

> The one that pushed me to the 1.3... camp was the VFAT file system and Another
> was improved drivers for my hardware.

The one that pushed me was appletalk support. The one that pushed RedHat
in their shipped kernels was 2940 support.

> I personally see no reason why someone other
> than Linus should take an effort to stabilize a release for those chosen
> features.

From the context, it sounds as if you meant the reverse of what you
actually said. I see no reason why it shouldn't be done, provided it is
done properly. I would never undertake such a plan without Linus'
express blessing, as the danger of kernel divergence is too great. If
someone wants to help lighten the load, though, this is not per se
objectionable, provided it is feasible.

> You
> know experience can be a great teacher.

Exactly, and it was learning from experience, rather than any criticism,
that I was attempting. (Just wanted to make that clear.)

Many new kernel drivers, be they network, fs, or hardware, are, I
suspect, sometimes tied in with deeper kernel developments (like
restructuring the vm stuff.)

For those that aren't, however, it would be nice if they could be moved
into stable versions more quickly. If this is unfeasible, then forget
it; users can either wait or upgrade. If it is doable, however, it'd be
nice to see the next time around.

_____________________________________________________________________
Todd Graham Lewis Core Engineering Mindspring Enterprises
tlewis@mindspring.com (Standard Disclaimers) (800) 719 4664, x2804


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:1.553 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site