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

_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Reply via email to