Re: divergence from upstream as a bug
George Danchev <danchev@spnet.net> 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
Reply to: