lkml.org 
[lkml]   [2005]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFD: Kernel release numbering
    On Thu, Mar 03, 2005 at 02:33:58PM -0500, Dave Jones wrote:
    > If you accelerate the merging process, you're lowering the review process.
    > The only answer to get regressions fixed up as quickly as possible
    > (because prevention is nigh on impossible at the current rate, so
    > any faster is just absurd), would be more regular releases, so that
    > they got spotted quicker.

    Right. My point, and I think Jeff's, was that being extra careful for
    the 'even' releases and waiting around N days to see whether someone will
    finally test the -rc and see that it is broken impedes the whole process.
    Getting more people to test is not necessarily a function of the wait
    duration.

    > > Dave has been building "unstable" bleeding-edge Fedora kernels from
    > > 2.6.x-rcM-bkN, as well as "test" kernels for Fedora updates;
    >
    > Actually only rawhide (FC4-to-be) has been getting -rc-bk patches.

    When Arjan started testing 2.6, he set up a repo, and FC1 users at
    the time could just pull rpms from that repo. I and many others did it.
    Currently I'm rolling my own, so I haven't been consistently testing
    your Fedora kernels, rawhide or update, but I occasionally do the "grab
    the SRPM from Rawhide and rebuild it on FC3"-thing for my laptop. I
    think that we should institutionalize that.

    > The FC2/FC3 updates have been release versions only, with -ac patches.
    > (and also some additional patches backing out bits of the -ac)

    I've watched you periodically announce "hey, I'm doing an update for
    FC3/FC2, please test" on the mail list, and a handful of people go test.
    If we could convince many of the the less risk-averse but lazy users to
    grab kernels automatically from updates/3/testing/ or updates/3/unstable/
    as part of "yum update", and have a way to manage the plethora of (even
    daily) kernel updates by removing old unused kernels, then we'd only
    have to convince them *once* to set up their YUM repos, and then get them
    to poweroff or reboot [or use a Xen domain] occasionally. :-)

    > This is part of the problem with rebasing the existing releases to
    > new kernels. It's shoving a largely untested codebase into a release
    > that was never tested in that combination. It's expected that some
    > stuff will break, but the volume of breakage is increasing as time goes on.
    > Even if _I_ stopped rebasing the Fedora kernel, some of our users
    > will still want to build and run the latest kernel.org kernel on their
    > FC2 boxes. We shouldn't be expecting them to have to rebuild half of
    > their userspace just because we've been sloppy and broke interfaces.

    Yes, this is miserable, and exacerbated by the inability of almost all
    distros to deal with multiple installed versions of packages, or easily
    roll back changes, which crimps my argument w.r.t. wider testing, since
    the typical user willing to test while otherwise doing useful work wants to
    be able to roll back easily if there is a serious problem.

    The LVM packaging situation between 2.4 and 2.6 illustrated the problem
    well; one couldn't boot back into 2.4 unless LVM1 and LVM2 userland
    could coexist; I spent time rolling packages back then to do just that.
    In any case, kernel helper packages (udev, device-mapper, iptables, etc.)
    need to be added to a "kernel+related" package repo.

    Users could be encouraged to do more testing if they are provided
    with a simple mechanism to snapshot, update, test, and then either
    keep the changes or roll back. I do this in UML with the COW tools.
    Currently LVM2 has writable snapshots, but no easy way (at system boot)
    to reintegrate the changes into the base from a snapshot, or "fallback"
    to a snapshot. Still, using Xen/UML/QEMU, it is not difficult to take
    advantage of copy-on-write to update the kernel and other packages, then
    boot the image to start a shell or web/ftp/mail/... daemon(s). At least
    that would exercise the non-hardware-related, (and for now, non-SMP)
    parts of the kernel.

    Bill Rugolsky
    -
    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: 2005-03-22 14:10    [W:4.226 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site