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 <[EMAIL PROTECTED]> Detailed patch description Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
