Re: kernel dev methodology

Robert Riggs (rriggs@tesser.com)
Wed, 20 Mar 1996 03:46:41 -0700 (MST)


>
> One of the most desirable aspects of linux is the software engineering
> talent that can be brought to bear on developing new kernel
> features/drivers/bug fixes quickly. Would it be at all worthwhile to
> entertain a discussion on a revised kernel development/release model that
> incorporated a central defect tracking repository and parallel kernel
> development and release tracks. New kernel features from the development
> track could be developed on the release base in parallel, merged in to the
> current base individually, tested and certified as release candidates in a
> more structured manner. The goal being more features sooner, maybe even a
> more scalable kernel development effort.
>
> Now all we need is a GNU Atria ClearCase clone.....
>
>
>
>

If the main goal that you are proposing is to continue updating
the current stable release (in the current case 1.2.x) with new
driver versions, small bug fixes and small upgrades/enhancements
(such as ELF kernel compilation) during the development phase,
I agree wholeheartedly.

The current scheme of just dropping any further development on
the stable kernel is not helpful to the development team. This
practice leads to more newbies trying development kernels in
order to get their hardware supported. This causes (as everyone
subscribed to linux-kernel can attest) much frustration since
kernel development by its nature will cause some programs to
break, leading people to come asking "why does 'foo' not work
any more?" when that problem was fixed 2 monthes ago.

Kernel development cannot occur in a vacuum. We need people
pounding on the kernels with varied hardware. There will always
be people who need to be "on the bleeding edge." With Linux's
popularity growing as it is, we will not run out of people
willing to risk crashing their machines for the fame and
glory of having squashed a kernel bug.

Linux has become a *very* popular OS. Its popularity will
only increase. Many people are using Linux in mission
critical applications and can't afford the hit-and-miss
approach to trying development kernels in order to support
newer, better, faster hardware. It took almost a year to
complete 1.1.x development. It looks like it will be about
the same for 1.3.x. That is an eternity in the world of
computers. We need to get hardware support into the
stable kernel much faster.

Many of the new drivers and driver updates already are set up
to be dropped in to the stable kernel release anyway. There is
little work needed to support this update process in most cases.
The authors of these drivers, in making their software compatible
with both kernel versions, are already debugging under both
platforms. Their workloads should not increase. When this is not
the case, porting stable drivers from development to stable
kernels is a wonderful way to introduce people to kernel
hacking.

The task of maintaining the stable release is something
that needs to be delegated (sanctioned) by Linus. We do
not want the maintenence of the stable release to impact
kernel development. As it is now, it would take no more than
a few days to compile the new drivers that are availible
and create a patch for 1.2.14. All we need is someone to
keep track of new driver releases and patches. If the
stable kernel were only updated monthly, it would make a
huge difference.

As Linux continues it's march towards world domination, the
sheer number of users will begin (already is?) overwhelming
the development process. We need a reliable and up-to-date
stable kernel series. A year is far too long to wait for
new hardware support in the stable kernel. Maintaining the
stable release should be relatively easy.

Rob
(rriggs@tesser.com)