On Sunday 18 May 2008, Ben Finney wrote: > George Danchev <[EMAIL PROTECTED]> writes: > > You seem to forgot that people will actually work with the source > > code and actual patches applied to it, not with a bunch of patches > > floating in Debian BTS with not so clear/predictable state > > (applied/unapplied/blamed/whatever). Such a service to can only be a > > companion one, but not a reliable source of what has actually > > changed, so consider it 'yet another place to DIG at'. > > Whether the patch is in the bug report or not, I don't see how that > affects the proposal. > > > 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".
Although not mentioned in the first place these are all unavoidable consequences you will face at some point. > 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. > > It *suggests* that, with such a classification, certain workflows > would be enabled naturally; but it doesn't *insist* on any of them. > > There's merely the proposal that we start *tracking* the divergence as > a bug that needs resolution, like any other bug report in the BTS. Such a classification may exists, but it is not a reliable source of code changes and their states which are actually deployed and are being in use. > Am I wrong? Well, not wrong, but you ask for too much load for almost no gain in solving the problem of exposure of debian changes for easy public peer review. -- pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
