Re: Development tree, PLEASE?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





--On January 20, 2006 6:08:52 PM +0100 Gábor Lénárt <[email protected]> wrote:

Though I'm not a kernel developer let me allow to comment this based on
my experiences as well.

On Fri, Jan 20, 2006 at 08:17:40AM -0700, Michael Loftis wrote:
OK, I don't know abotu others, but I'm starting to get sick of this
unstable stable kernel.  Either change the statements allover that were

What kind of instability have you got? I haven't had any instability since
at least a year or so, or if there was it was some kind of hardware fault.
In fact, many machines (like an Armada E500 notebook and some servers as
well) seems to be stable which was NOT in case of 2.4 kernels! So for our
experience at our workplace, 2.6 seems to be much more usable than 2.4.x
kernels (ok, it may be caused by "newer" hardwares, on quite old machines
I can't show major difference in stability between 2.4 and 2.6)

There's two parts of stable in most of the development world, runs on my hardware reliably/runs on most hardware reliably is one part, the other part is limited change, usually limited to bugfixes and minor feature fixes or updates. This means that instead of having to take how ever many (probably thousands on thousands) of lines of difference, and any of those potential new bugs etc, to a much reduced set that just deals with specific subsections in order to close specific bugs. Be it a minor change to fix support for a new PCI ID, or a a buffer overflow. API changes or relocation of headers and such would be kept out of a stable branch. It's that second part I hear see and have objections about with 2.6 as it sits. There's no 'place' for bugfixes to centralize. I know that a number of my problems are fixed in later kernels, but there's a LOT of fairly large change between where I am, and where current is. Far more than would be in a normal stable piece of software.

<...>

Ah, I see your point. But is it really a BIG problem? I mean please
mention some *real* issue/story confirm your opinion. Sure, you can find,
but also compare it with the advantages of new development model, since
there is nothing in the world which is only have advantages neither
something which only has disadvantages ... The would is not black or
white, but a great spectrum of gray shades.

Yup, from 2.6.8 sometime after 2.6.8 aic7xxx is pretty clearly broken from many reports I've seen, it was finally fixed in 2.6.15 (I do not know hte bug exactly, sorry, I'm using others reports). In 2.6.8 it's a little broken, but mostly working. If there had been a major bug between there and .15 that required me to upgrade to close a security hole I'd have been stuck, unable and impossible to upgrade, for that one reason alone. Worse than that because there is so much major change now I have to stress test basically every kernel before we can actually start to use it at my day job. We host well over 10k busy mostly dynamic (PHP, Perl, Miva, other stuff) web sites on a cluster of Linux based servers. If there's subtle problems they show up in a big way usually, and having them in production is not acceptable.

If there was a stable branch with a low change rate then it's easy to track the changes even just 'visually' without necessarily having to go through a whole stress testing procedure.

I'm not saying an increased/rapid development pace is a bad thing. I'm just wondering where the refuge from that is for systems that don't need, don't want, or really can't have that level of change happening, without resorting to maintaining ones own kernel fork. It's one thing to compile/package ones own custom packages for a distro when you're already using custom kernels or not using their kernel, or even if you're just using your own, it's another to actually really maintain your own tree by oneself.

Yes I agree with what others have said, it gets to be more and more work. Perhaps something along the lines of 3 6 or 9 months with 1 or 2 'community supported stable releases' -- in my day job i'd personally like to see longer terms, but ~6 months would be manageable atleast as to major change bumps.


Yes, I'm venting some frustrations here, but I can't be the only one.  I
know now I'm going to be called a troll or a naysayer but whatever.  The
fact is it needs saying.  I shouldn't have to do major changes to
accomodate sysfs in a *STABLE* kernel when going between point revs.
This  is just not how it's been done in the past.

sysfs should not used by an average application, I guess, so it's not a
major point

No not in itself. I'm looking at a LOT bigger issue. Everyone seems to want to look at and work with a tiny little piece, but there's the bigger issue of what is stable. What does it mean to be stable. In the minds of the people I've worked with directly it's always meant the two things outlined earlier. Runs reliably, and is in a maintenance mode (yes, synonymous maybe with stagnant). That means that it is necessarily a fork, away from the main line(s) of development and work. But it serves a purpose in many environments. It's utility is lost in the average desktop, but in the corporate desktop, in servers, embedded devices, commercial products, etc. it's a big win.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux