lkml.org 
[lkml]   [2009]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] to rebase or not to rebase on linux-next
    Theodore Tso wrote:
    > I think we need to be a bit careful in this discussion. There are two
    > things that cause a particular git tree to be one which can't be used
    > as a the basis for subtrees. One is "rebasing", where a series of
    > commits is dropped onto a new version, or base, hence "rebasing". The
    > other is where one or more commits are *modified* --- perhaps to add
    > ack-ed by, or tested-by comment lines, or to improve comments, or to
    > fix outright bugs in the the patch series. Perhaps it's better to
    > call this "rewinding", since in most cases this doesn't actually cause
    > a change in the "base" of the patch series.

    That's helpful terminology.

    > The reason why it's important to make this distinction is that some of
    > the arguments about why constantly changing the base of a patch series
    > don't apply when we are just fixing up patches in the patch series or
    > git tree.
    >
    > So given that, why do I think "rewinding" has a place as a development
    > methodology for patch sources that feed into linux-next.

    Though per definition of what is expected to be submitted into
    linux-next, both rebasing and rewinding should occur rather rarely.

    Instead of a process rule that for-next branches should not be rebased/
    rewound, I would suggest that
    If a for-next branch is rarely rewound, let alone rebased, it is an
    indicator that development and maintenance of a tree are going well.
    And vice versa.
    stands as a /rule of thumb/. Actually, that's all very obvious because
    a for-next branch is pretty much a /release/ branch.

    > 1) Linux-next is by definition a constantly rewinding branch. It is
    > thrown away and recreated every day, based on the tip of Linus's

    [It is not entirely thrown away, see
    http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=tags. But
    it is indeed recreated daily, i.e. next-N does not include the end
    result of next-N-1.]

    > mainline tree, and so the date of the merge commits means that you can
    > never base anything on top of linux-next. This has always been the
    > case, and so trying to impose a straightjacket on all of the sources
    > of linux-next doesn't actually buy anything as far as the properties
    > of linux-next.
    >
    > 2) There are many legitimate reasons for "rewinding". In addition to
    > being able to add credit for tested-by and acked-by lines, sometimes

    Per linux-next submission rules, all /essential/ credits are already
    present. But I agree that it is worth rewinding a for-next branch in
    order to add (non-essential) credits later. linux-next's exact history
    is of interest for days or months at most, while mainline's history is
    of interest for many years to come.

    > patches are subtle. More than once, patches have been sitting in the
    > ext4 tree that have passed the XFSQA test, and thus have been "unit
    > tested", but they still have bugs; in some cases, subtle bugs. In
    > some cases, bugs that cause data corruption. In the case where the
    > patches have hit linux-next, but the merge window hasn't opened yet, I
    > prefer to fix the patch by mutating it, and rewinding the ext4 tree,
    > instead of adding a fix later. It makes it easier to cherry pick
    > patches to the stable tree later, and it keeps the ext4 tree clean,
    > and it has no downside in terms of linux-next --- see (1) above.
    >
    > 3) I don't have the same access to vast amounts of hardware and
    > platforms that Ingo does. As a result, while I make a practice of
    > testing every single patch against the XFS test suite (yes, it's slow
    > and painful, but I think it's worth it; I'm very paranoid about patch
    > quality), every once in a while the patch has warnings or doesn't
    > compile on some platform for which I don't have build/test machines.
    > Today, this gets tested in linux-next, and when it does, if it the
    > merge window hasn't opened yet, I will fix it the patch instead of
    > creating an extra patch. This helps git bisectability for platforms I
    > don't have access to.

    We should rely less on linux-next as a cross-compile farm; that's not
    its purpose. We can cross-compile ourselves. I think the documentation
    and toolchain can be found somewhere. In fact, we are supposed to do so
    per item 3 in Documentation/SubmitChecklist. This text was added about
    two years before linux-next opened for business.

    That said, I admit that I don't test more than x86-64 myself (x86-32
    too, but decreasingly frequently now). But that's mostly because I only
    deal with code where the danger of architecture-dependent build breakage
    is very low. (drivers/ieee1394 is frozen, and drivers/firewire is
    small, modern, sparse-clean, and uses clean interfaces to the rest of
    the kernel. There is some more danger of /runtime/ regression of these
    drivers on other architectures, but those would only be exposed in
    mainline or distributions, not in linux-next already.) I guess on the
    unlikely day that I get notice of a linux-next build bug due to my tree
    on one of those platforms, I will reorder my never ending to-do list and
    set up local cross compilation.
    --
    Stefan Richter
    -=====-==--= =-=- ==---
    http://arcgraph.de/sr/


    \
     
     \ /
      Last update: 2009-10-24 14:23    [W:0.032 / U:118.148 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site