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". 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. Am I wrong? -- \ "I hate it when my foot falls asleep during the day, because | `\ that means it's gonna be up all night." -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
