Re: divergence from upstream as a bug
On Sunday 18 May 2008, Joey Hess wrote:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
> Everything else follows from that quite naturally..
I have read that mail several times and I believe that "divergence from
upstream as a bug" is not the precise enough, it should be put instead "hard
to get for peer reviewers divergences from upstream is a bug".
I'll give you an example with aalib (one of your packages where you are not
upstream). External peer reviews (upstream developers, regular debian users
and possible NMUers) are not supposed to follow your tools of maintaining the
package to have a clue what changes you have done to the upstream code, nor
they need your assistance receiving these patches asynchronously in their
mailbox at your demand (since you may be MIA, VAC, patches burried in spam,
etc). Instead they should be able to recognize on their demand in a fast and
unified fashion all the logical changes you have applied to their upstream
code. Having that said I can't easily recognize how many logical changes to
the source code have been applied with your diff.gz, worst they are even not
documented within your maintainer's files. You can also ask your upstream how
easy they can recognize these changes without your help.
I strongly believe that this is what should be improved, and there is no any
urgent need for more infrastrucre enhancements and yet another places to look
at (like teaching BTS/PTS of doing additional DD-upstream communication
processing which brings even more complexity to the scene). In the world of
diversion, there should be a single point of unification one can safely
return to.
--
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: