[lkml]   [2004]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Inclusion of UML in 2.6.8
    On Sun, 2004-06-27 at 08:40, Andrew Morton wrote:
    > Paul Jackson <> wrote:
    > >
    > > > I'm looking at quilt
    > >
    > > Good tool.
    > >
    > > It's a bit like a loaded gun with no safety. You will learn a few new
    > > ways to shoot your foot off, and become good at first aid.

    Ideas for improvement are always welcome -- they would best be discussed

    > > You will
    > > want someway to keep personal revision history of your patches, to aid
    > > in such repair work. CVS or RCS or local bitkeeper or (for ancient
    > > hackers like me) raw SCCS or some such. Quilt handles the patches, but
    > > in and of itself has nothing to do with preserving history.
    > >
    > > All software is divided into two parts - the concrete and the fluid.
    > >
    > > Once something is accepted into the main kernel, it's concrete. You can
    > > never go back - you can only layer fixes on top. Bitkeeper rules for
    > > this stuff.
    > >
    > > But work in progress, for which oneself is still the primary source, is
    > > fluid. You can slice and dice and redo it, and indeed you want to, to
    > > get the best patch set. Quilt and friends rule for this stuff.
    > Good description, that. quilt is a grown-up version of patch-scripts, and
    > is tailored to what I do, and to what distributors do: maintain a series of
    > diffs against a monolithic tree which someone else maintains.

    The concepts behind quilt are all stolen from patch-scripts, so it has
    the same usability problem that patch-scripts has: forgetting to add a
    file to a patch before modifying it is painful. the ``quilt edit''
    command helps somewhat. I do not have a good idea how to fix this in a
    more satisfactory way.

    Quilt is missing some of the features of patch-scripts: there are no
    equivalents to export_patch, which renames exported patches so that the
    filename sort order equals the order of the patches in the series file.
    Neither is there a way to strip such sequencing prefixes when importing
    patches. (I consider this obsolete.) There is nothing kernel specific,
    and nothing specific to version control systems. Also there are no
    equiovalents to patch-scripts's new-kernel, mv-patch, patch-bomb,
    pstatus, rename-patch, tag-series, commands.

    On the other hand there are lots of small improvements, no more patch
    control files (that list the files a patch touches in patch-scripts),
    improved diffing and status inquiry functionality, patch dependency
    analysis, support for RPM packages. And there is more documentation.

    Things I'm currently considering include:

    - handling of meta-information such as one-line summary, author,

    - support for diffstat (re-add; we had this in older versions),

    - a patch-bomb equivalent.

    All of the above things will potentially conflict with the goal of
    keeping the whole thing as policy-free and generally useful as possible.
    > > Conclusion - use Quilt (with your favorite personal version control) on
    > > top of Bitkeeper.
    > yup. I use patch-scripts+CVS in the way which you describe.

    Same here.

    Andreas Gruenbacher <>

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.024 / U:1.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site