On Sat, Dec 03, 2005 at 09:59:11PM +0100, Lars Marowsky-Bree wrote:
> On 2005-12-03T14:56:08, Adrian Bunk <[email protected]> wrote:
>
> > The current kernel development model is pretty good for people who
> > always want to use or offer their costumers the maximum amount of the
> > latest bugs^Wfeatures without having to resort on additional patches for
> > them.
> >
> > Problems of the current development model from a user's point of view
> > are:
> > - many regressions in every new release
> > - kernel updates often require updates for the kernel-related userspace
> > (e.g. for udev or the pcmcia tools switch)
>
> Your problem statement is correct, but you're fixing the symptoms, not
> the cause.
>
> What we need is an easier way for users to pull in kernel updates with
> the matching kernel-related user-space.
>
> This is provided, though with some lag, by Fedora, openSUSE, Debian
> testing, dare I say gentoo and others.
>
> The right way to address this is to work with the distribution of your
> choice to make these updates available faster.
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.
It still isn't to solve the problem of regressions in drivers, but
that's a problem that's not easily solvable.
Dave
-
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]