From: Andreas Gruenbacher <agruen@suse.de>
To: Andrew Morton <akpm@osdl.org>, Paul Jackson <pj@sgi.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Inclusion of UML in 2.6.8
Date: Sun, 27 Jun 2004 15:50:00 +0200 [thread overview]
Message-ID: <1088344199.21940.62.camel@winden.suse.de> (raw)
In-Reply-To: <20040626234025.7d69937c.akpm@osdl.org>
On Sun, 2004-06-27 at 08:40, Andrew Morton wrote:
> Paul Jackson <pj@sgi.com> 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
on http://lists.nongnu.org/mailman/listinfo/quilt-dev.
> > 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, unitdiff.py 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,
description,
- 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.
Cheers,
--
Andreas Gruenbacher <agruen@suse.de>
SUSE Labs, SUSE LINUX AG
next prev parent reply other threads:[~2004-06-27 13:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-26 17:05 Inclusion of UML in 2.6.8 BlaisorBlade
2004-06-26 18:10 ` Christoph Hellwig
2004-06-27 3:53 ` Jeff Dike
2004-06-27 13:57 ` Rik van Riel
2004-06-28 10:55 ` Arnd Bergmann
2004-06-29 19:29 ` Uploaded Uml patchset for 2.6.7(was: Re: Inclusion of UML in 2.6.8) BlaisorBlade
2004-07-03 18:25 ` [uml-devel] " BlaisorBlade
2004-06-26 20:09 ` Inclusion of UML in 2.6.8 Andrew Morton
2004-06-27 3:59 ` Jeff Dike
2004-06-27 6:32 ` Paul Jackson
2004-06-27 6:40 ` Andrew Morton
2004-06-27 8:08 ` Paul Jackson
2004-06-27 13:50 ` Andreas Gruenbacher [this message]
2004-06-27 23:43 ` Paul Jackson
2004-06-28 21:18 ` David Eger
2004-06-27 8:53 ` Geert Uytterhoeven
[not found] ` <20040628181134.GA21360@havoc.gtf.org>
[not found] ` <Pine.GSO.4.58.0407201754460.23496@waterleaf.sonytel.be>
2004-07-22 13:09 ` [PATCH] cirrusfb: update for amiga (zorro) David Eger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1088344199.21940.62.camel@winden.suse.de \
--to=agruen@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox