On Sat, 17 May 2008, Joey Hess wrote: > Raphael Hertzog wrote: > > On Fri, 16 May 2008, Joey Hess wrote: > > > Coming up with a complex set of requirements that everyone has to follow > > > up front in their workflow[1] is not going to yeld the best results, and > > > I think that's my core reason for disliking Raphael's proposal. Now, if > > > you can come up with protocols/interfaces that can be used to > > > publish/communicate patches, that are managed/generated in whatever way > > > is most useful for the maintainer, that seems more likely to work. > > > > Aren't "patch files in debian/patches/ with some headers" a defined > > interface? > > It's an interface, that if you stop there in defining it, means that I > have to check debian/patches/ into revision control, and bloat my > .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source) > with them.
You don't have to check it in revision control, you just have to be able to generate them from revision control. For .diff.gz, we already have tools to handle such files properly (without duplicating their content), it's called quilt or simple-patch-sys of CDBS and you know it (but you don' like those). For .git.tar.gz, if you have a tool to generate the patches, it would be possible to hook it into the automated system that uploads patches to patches.debian.org. If that process is not the same across all .git.tar.gz, we can mandate a new debian/rules target that must generate a debian/patches directory with all the patches. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
