On Sun, May 18, 2008 at 04:54:28PM +0200, Lucas Nussbaum wrote: > On 18/05/08 at 16:48 +0200, Mike Hommey wrote: > > On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote: > > > On 18/05/08 at 11:27 +0200, Mike Hommey wrote: > > > > 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) > > > > > > No, you would need to untar the .debian.tar.gz file, so upstream can > > > browse the patches. > > > > And? You also have to untar the source .tar.gz from upstream web site... > > It sounds better to be able to tell upstream: > patch available from http://......./the_patch.diff fixes that. > Rather than: > patch the_patch.diff in http://...../foo.debian.tar.gz fixes that.
It sounds better to send the patch directly instead of telling upstream to go to some random place to gather it. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
