Messages in this thread | | | Date | Sat, 3 Dec 2005 22:18:10 +0100 | From | Lars Marowsky-Bree <> | Subject | Re: RFC: Starting a stable kernel series off the 2.6 kernel |
| |
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/
| |