diffoscope 77 in stretch or not?

Ximin Luo infinity0 at debian.org
Tue Feb 14 20:44:00 UTC 2017


Holger Levsen:
> On Tue, Feb 14, 2017 at 09:38:51AM +1300, Chris Lamb wrote:
>>> what did you plan on to do with diffoscope in regard to Debian's
>>> stretch when you decided to work on it
>> I didn't decide anything at all; I was enjoying the coding, adding
>> features, tests, squashing bugs...
>  
> you decided to put this work into the master branch though and to upload this
> to unstable, while you certainly were aware of the freeze (which is always
> the reasons for tensions btw) and the surrounding policies.
> 
> Me too would have appreciated and expected some discussion about this, eg 
> a simple mail to the list "what shall we do, I think we should push $this
> into unstable and stretch".
> 
>> (However, whatever version ends up in stretch will surely become pretty
>> outdated that we will be sending people to Backports within a few
>> months anyway, so I'm not overly concerned about this.)
> 
> well, whatever we put in stretch now has been tested on 25k packages in
> Debian plus a bunch of other projects, so, yeah, whatever, it might become
> slightly outdated in a while, yet diffoscope today is quite great and deserves
> proper care.
> 

I do generally agree with this and have been concerned about the specific pace of diffoscope commits in the past few weeks. Not only because of the security issue [1], but because it is bypassing the normal Debian process a bit.

I don't think it's good to "try an unblock b/c we have good relations with that team", this type of personal/social politics is not how I'd like to see Debian function. Personally I would prefer it if the release team forced us to backport the security fix and kept the stretch version at 67+security1 because that would be "more fair treatment".

I do think it's OK to try to support diffoscope 67 for 2 years because it's been quite well tested. The core functionality is all there, and people have been using it for ages. There's no need to rush things into unstable, we can push to experimental until the freeze is over.

I understand that 77 fixes quite a lot of bugs over 67, but this could have been done without the other changes (which could have been made in a side branch). And that would be more in line with the "normal unblock process".

X

[1] I have other words to say about that but unfortunately some people don't like how I choose to express things

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



More information about the Reproducible-builds mailing list