Matt Zimmerman wrote:
On Thu, Jun 02, 2005 at 12:25:01AM -0400, Joey Hess wrote:If Debian treated our upstreams this way, I'd be suprised if we ever got any patches accepted upstream.Debian does, in fact, treat most of its upstreams precisely this way. Debian publishes a large portion of its changes primarily in the form of monolithic diffs relative to upstream source. The last time I saw figures, the usage of dpatch, cdbs, etc. was rising, but not yet the standard operating procedure.
I know it has been said before, but that is not true. For packages with active upstream, I always send individual patches upstream. For packages like mysql-admin, or mysql-query-browser, there is no dpatch, etc. used because that would be inefficient. Upstream is very fast at fixing things and the few, small patches that there are, can be fixed by hand. For vast majority of cases, the huge .diff.gz patch is for the /debian directory and sometimes to update the config.sub and config.guess files. I don't think upstream would wade though .diff.gz files anyway. Huge Debian patches like that just make the work of the maintainers, not upstream, more difficult.
Low usage statistics for dpatch, cdbs, etc. don't imply that upstream doesn't get manageable patches.
- AdamPS. We already saw that a fork or derivative of upstream can warp into something that will waste a lot of man hours to port with the Apple's browser (derivative of Konqueror). Their huge patch cannot be easily incorporated to the new version of Konqueror meaning that Apple, not KDE, will be wasting a lot of their time porting that patch to the new versions of the browser. Similarly for non-Ubuntu specific changes, it is in Ubuntu's interrest (not necessarly Debian's) to have those patches accepted in Debian. I think this is especially true for those critical, base packages.