[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: the quality of Debian's diff.gz



On Sunday 01 June 2008, Don Armstrong wrote:
> On Sun, 01 Jun 2008, George Danchev wrote:
> > Because people would hardly trust BTS for sourceful changes being
> > applied to a particular source tree.
>
> The point of the BTS in this regard is to track the issues that lead
> to divergence; as a bonus you get a patch attached. If you don't trust
> that the patch attached by the maintainer is actually the patch that
> the maintainer is using, how are you going to trust the VCS or even
> the diff.gz in the archive is the actual patch that is being used?

Because diff.gz along with .orig.tar.gz and .dsc is what you actually feed 
buildd with, and is actually burnt on Debian offical images. OTOH wrong patch 
set could be sent to the BTS, erroneous bug manipulations do happen by 
accident... why yet another player must be added to the patching game, isn't 
it complicated enough yet for overloaded parties:
http://lists.debian.org/debian-devel/2008/05/msg00623.html

> Furthermore, linking a divergence to a VCS revision is pretty easy,
> and upstreams resolving the divergences will lead to the relevant
> patches disappearing anyway.
>
> > Sure, that sounds pretty good to me, but would probably take decades
> > to deploy all debian source packages 3.0 (git) way, since 3.0
> > (quilt) is currently on topic.
>
> Huh? This isn't an either/or situtation. We can have many SCM/VCS
> package formats in Debian. If review of them is something that you
> really want to see happen, you can make unified frontends to those
> SCM/VCS that reproduce a stack of patches.
>
> All this takes is someone doing the work; there's nothing inherent in
> any of the modern DVCSes that makes this impossible.

If these tools are not ready yet, why unreadable diff.gz have been uploaded to 
the debian archive ? I'm sorry, but doing uncoordinated moves causes a 
massive disturbance in the trust. I'm utterly disappointed, and will stop at 
that point.

-- 
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: