On Sun, May 18, 2008 at 01:14:09PM +0000, Ben Finney wrote: > George Danchev <danchev@spnet.net> writes: > > You wil have hard time teaching every upstream in Debian BTS (new) > > tags and features, but they all already know how to deal well > > prepared diffs from debian ftp mirrors. > > I've gone back to re-read the original proposal that starts this > thread, and I can't see where everyone is reading "bureaucracy" and > "extra workload" and "patches floating in the BTS" and "forcing > upstream to read new BTS tags and features". > > The proposal, at its core, is merely about how to *classify* > divergence from upstream source in a Debian package. There's nothing > in the original message that requires patches to be duplicated, or > upstream to get patches in a different way, or any of the other > spectres people are raising here. That's additional work. That's creepy and uninteresting work to begin with, its useless with proper upstreams, and is needed only for bad upstreams, that won't eve take a glance at all that work ever. Yay. That's kind of what I call bureaucracy indeed. What _would_ help is helping maintainers to report bugs upstream, whatever the upstream way of tracking them works, with a unified method/tool/whatever. _That_ would be more than useful. And it could probably do what we're discussing as a side effect of reporting the bug upstream. That would be in the end _LESS_ work for the maintainer, as it eases the report to upstream, while having all the side effects you want. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpdJq6PGgLcQ.pgp
Description: PGP signature