On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote: > 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.
Note how infrastructure needs would decrease considerably if packages were mandated to use v3(quilt) format: patches.debian.org would be ftp.debian.org and would just need nothing new (except for how source packages are created) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
