lkml.org 
[lkml]   [2006]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Development tree, please?


--On January 20, 2006 1:11:20 PM -0500 sean <seanlkml@sympatico.ca> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-20 19:46    [W:0.201 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site