Re: divergence from upstream as a bug
On Sunday 18 May 2008, Ben Finney wrote:
> Again, the BTS is not "yet another place"; it's already a place where
> Debian-specific information needs to be about other changes to the
> package. It's a proposal to *consolidate* information into a place
> that already has much similar information for similar purposes,
> instead of having that information scattered in many places.
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'.
> > What Joey's proposal is:
> > * put more burden on the maintainers that already report patch
> > upstream ;
> Are these maintainers not recording the fact of a bug in the BTS?
Yes, that activity is not bullet proof.
> > * has very few advantages for people that already did that work in
> > their source package in a decent enough way (like the glibc does):
> > the sole advantage I see is that it's predictable where to find the
> > information. But when you want to check a package you have to
> > `apt-get source` it anyways, and if debian/patches is sorted
> > properly, then you'll see that in an obvious way before even
> > launching your browser to look at the BTS.
> This assumes that 'debian/patches' is a known standard interface for
> all Debian packages, which I would think it clearly isn't in light of
> previous threads here. The Debian BTS, on the other hand, *is* a known
> standard interface for all Debian packages.
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.
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