Re: Development tree, please?

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

 





--On January 20, 2006 1:11:20 PM -0500 sean <[email protected]> wrote:

You see, that's exactly the problem.   Say you have a a mainline "stable"
tree called 2.8 which still had devfs in it, and a development branch 2.9
with it removed.   If you end up needing something new in the 2.9 branch
where devfs is remvoed you're in _exactly_  the same situation you find
yourself in now.

Except for there's atleast an old stable branch, as there has been in the past, and the change was made and having to track the NEW stable branch. Where do people apply security updates and patches to now that there's no stable branch out there? Or is that just discouraged now?

Essentially what you're saying is you need some stuff from the
development  branch (ie. why 2.4 is unacceptable to you today) but you
want to pick  and choose which pieces.

Negative, my big problem is the lack of a stable branch. 2.4 is really showing it's age in many places. Lack of hardware support, lack of a lot of networking improvments in 2.6, lack of SMP improvments in 2.6....the list is pretty good. If 2.6 isn't stable then why the 2.5->2.6 at all. Why isn't this still 2.5? because people want/needed a new stable rev.

I know there will *always* be problems and issues with picking any point in time, arbitrary or not, to say lets work up for a feature freeze for release. The Debian project knows this all to well. However the quality of their releases has been so much better than anyone elses, I still stick with them as much as I can.

When you need some of the pieces that are only in the latest mainline
kernels you just _have_ to accept that other things will have changed
as well.   Changing the names of things isn't going to change that one
bit.

OK so I should have to change all my userland utilities, installers, etc just because I need a new PCI ID? Or just because there's a *HUGE* bug in say, aic7xxx? devfs is just one facet of a potentially bigger problem. (which you do seem to understand, so...a lot of this reply is for the benefit of the larger audience)


Well you do have a point there, but the counter point still remains.   The
current mainline developers are just too busy to fill this role.   There
are costs associated with any model and the current model at least
reduces the costs borne by the mainline developers.   It would be nice
if someone would step up and provide a central repository for a stable
branch; but who?   I really don't know, but complaining to the current
mainline developers is the wrong approach to solving the issue.

If someone were to step up with a svn (or git...i'm not familiar with git yet though) or similar repository, would it be 'blessed' by the developers though, and able to maintain a version stream? This would give the community, and the developers that wished or were able a place to push out changes that are of a maintenance nature. Yes maintenance is a headache, but 90% of development is maintenance ;) atleast in the long view. I don't want, nor think that the developers should 'maintain' indefinitely old versions, but having a target for maintenance would be good, assuming it was 'blessed' and made to be a common place.

There's no doubt that there are upsides to a mainline stable tree.    The
point is that there are also _costs_.   _You_ have to suggest a solution
that would offer a stable mainline tree and not cost the current mainline
developers anything.


I understand the reason, but the problem it creates is it does give a
lot  of places incentive to just not contribute their bugfixes, and
instead fork  since they're not interested in getting involved in API
changes 'right now'.


Yes.   It's all about tradeoffs.   The current model spreads the costs out
to more people than just the mainline developers.   In the end it's more
fair than the older model and actually allows the developers to provide
us all with a better cutting edge kernel faster.   No doubt that there
are some downsides, but you haven't offered a way to pay for the costs
associated with going back to the old model.

OK well....we're certainly on the same page....and seem to have an idea of where to go. I guess just how to get there is the problem.

If a community effort was started...and provided we (this proposed community effort, which will probably have atleast some overlap with some mainline kernel developers) can get the blessing of the mainline effort I think it might work. Especially if one or more distro's would sign on to the effort and publish their maintenance and bugfixes there as well. The general idea being that a certain number of releases are picked to maintain as maintenance releases, hopefully with feedback from people on bugs and preferably with feedback of patches and/or commits to fix bugs and maintain a 'stable' branch that has atleast some hope of having a larger than one investment in keeping security updates atleast, and minor enhancements. There'd be someone ultimately responsible for it all, just as there is for the mainline, to coordinate and make releases based on that. Likely these branches/forks would be pretty quiet just fixing mainline bugs and minor things that are needed in the course of normal maintenance of a project.


Sean




--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
-
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