Re: divergence from upstream as a bug
On Sunday 18 May 2008, Ben Finney wrote:
> 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".
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
Reply to: