Re: How to cope with patches sanely (Was: State of the project - input needed)
On Sat, Jan 26, 2008 at 11:39:32PM +0100, Pierre Habouzit wrote:
> I'm less and less sure that a git-based format is a brilliant idea. I
> like git more than a lot, but it's a poor idea to base source packages
> on them. That doesn't mean that we shouldn't be able one day to upload a
> signed git source url + sha1 signed with GPG and see DAK and other tools
> git pull from there to rebuild the source package using some normalized
> ways, but a source package should remain as simple as possible, using
> _textual_ interfaces.
Something that we should be clear about is that there's a big
difference between the *interface* and the tool. One of the reasons
why the quilt *format* is so powerful is that it can be consumed by so
many different tools. For example, the quilt format can also be
consumed by "guilt" and "stgit" for git users, "mq" for mercurial
users; not just by quilt.
Just to give one example of how you can use a quilt *format* for a set
of patches without actually using the quilt tool. For the ext4 kernel
development, we use a svn-style central repository model, but using
git at http://repo.or.cz. Multiple poeple have access to push into
this central repository; it could have just as easily have been svn or
cvs, but a number of us like the ability of being able to have
off-line access to the repository. What we *store* in this repository
is a quilt-style set of patches, where the series files indicate the
base version of the kernel that the patches can be applied against.
How people manipulate the quilt series of patches depends on the
developer. Some developers use quilt, other (like me) use guilt. It
would even be possible for people to write a set of shell scripts to
parse the quilt series if they wanted; again, it is the format that is
important, not the tool.
One nice thing about the quilt format is they can preserve a large
amount of state. For example, we use the following convention in the
patch header:
<one line patch summary>
From: Author O' The Patch <author@example.com>
Detailed patch description
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This is at the beginning of every single quilt patch, and because of
this, we can easily important the patch into either a mercurial or git
repository, while preserving the authorship information of the patch.
So when it comes time to push patches to the upstream, it is much
easier to do so, since all of the information is right there.
Since we are keeping the patch series under source control, it allows
us to refine patches, and keep a historical record of the improvements
to a particular patch before it us pushed upstream.
So for the people who were concerned because quilt is unmaintained, I
wouldn't worry, because even if there is no one maintaining the
official quilt sources, there are plenty of other quilt work-alikes
that use the same format, and many of them are integrated into other
SCM's. Andrew Morton actually maintains is own private collection of
shell scripts to parse quilt patch series for his -mm kernel tree.
Andrew's tools is what the current quilt system is modeled upon, but
Andrew is still using his own set of shell scripts. So that's another
example of Yet Another tool that all use the same quilt series file
format.
> So maybe what we should do isn't trying to make the Debian source
> package a complex mix between a snapshot and a SCM, but rather let it be
> simple, and only a snapshot, and have ways to encode in it where to find
> (and how to use to some extent) the SCM that was used to generate it.
Yes; all a Debian source package should be is a snapshot of a series
of patches that can be applied against a source base. The series of
patches can be maintained in an SCM, and that's a useful thing to do;
but for the purposes of what you ship in a source package, the full
SCM data itself is not strictly necessary.
Regards,
- Ted
Reply to: