Re: RFC: Starting a stable kernel series off the 2.6 kernel

[Lars Marowsky-Bree <lmb@suse.de>]

On 2005-12-03T16:13:29, Dave Jones <davej@redhat.com> wrote:

> The big problem is though that we don't typically find out that
> we've regressed until after a kernel update is in the end-users hands.
> 
> In many cases, submitters of changes know that things are going
> to break. Maybe we need a policy that says changes requiring userspace updates
> need to be clearly documented in the mails Linus gets (Especially if its
> a git pull request), so that when the next point release gets released,
> Linus can put a section in the announcement detailing what bits
> of userspace are needed to be updated.

True, but this first block doesn't really qualify as a "regression".
Yes, a clearer-than-crystal documentation of "this kernel requires
user-space component foo to be at least x.y.z if feature bar is used"
would go a long way.

And if then user-space itself was tolerant of at least version N and
N-1, then users could even roll back one kernel version if problems
arise.

Both of these are documentation and user-space issues, and don't much
depend on changes to kernel development model.

> It still isn't to solve the problem of regressions in drivers, but
> that's a problem that's not easily solvable.

True. Regressions will always occur when driver updates happen. There'll
always be the next bug. I don't think anyone introduces these on purpose
;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

-
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/