Messages in this thread | | | Subject | Re: kernel dev methodology | Date | Wed, 20 Mar 1996 03:46:41 -0700 (MST) | From | Robert Riggs <> |
| |
> > 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)
| |