Hi Marc, Starting with this... > I have to say that in the last few years the relationship with the > release team has been of much better quality, more collaboration to > find a solutions together than the BOFH style that was when I first > joined. Here it looks like our arguments are just discarded out of > fear, not by rational analysis. So I feel quite disappointed by how > this BR (and #923885) have been handled so far. I am really sorry that you are perceiving it like this. Bear with me. There are more capable release team members then me, but we're all busy. I am not in the position to perform "deep analysis", mostly because I don't consider myself a programmer and limited time. I can code in scripting languages, but I have never learned to code in C. Obviously I am hesitant. We had more unblocks to deal with, and several weren't easy either. On 06-06-2019 04:23, Marc Dequènes (duck) wrote: > On 2019-06-04 03:53, Paul Gevers wrote: > >>> About this alternative version here: > > Thanks Jens for your help. Comments later on. > >> We prefer this route. > > I provided, as well as other maintainers, maximum information to give > the release team proper materials to get to a decision. > I'd like to have your rationale on this preferred route please. > Currently if feels like no deep analysis was done. Sorry, but also see the above. On top of that, we have had multiple difficult unblock requests and there is so much time in the free part of the day. Going left or right, your request didn't comply with the freeze policy so it requires an exception. So far, you haven't gotten it. I *am* spending time on it. The issue is that *I* am not confident to bless the version in unstable. The alternative version that Jens provided is much better review-able and *we* agreed that that version could be unblocked. >>> I assume a fix for #914794 (libmspack fails tests on big endian >>> architectures (s390x, mips)), reported against 0.9.1-1 is not necessary. >>> However if that was caused by a change in the toolchain instead of >>> changes in the package, I'll also add that fix here. > > This is what caused this situation in the first place, so unless the > release team decides to drop mips and other big endian architectures, > this is a no go. > I did not test the build on these architectures myself with 0.8 but I'm > basing this on upstream's comment that nothing had changed in this area. > Once again it feels the release team did not take time to check on this > case. Which is true on my part. >> Please align. I'll unblock the targeted fix you propose above. Seeing >> the progress on the current package, I don't think you should expect the >> current version to be unblocked before buster. > > I don't understand what progress you're expecting here. We were all > waiting for the release team's decision, or a proposal of what would be > an acceptable upload. > > Currently the current version has been sitting in unstable for three > months without any single bug reported, this feels like a good progress > towards saying this version is safe. It's a valid argument for sure. > I'm not committing to this plan for the above stated reasons. I also > feels uncomfortable uploading with a know security problem, so unless > upstream or our security team says it's low risk, I'm not taking such > responsibility. Sorry, I am mising something here. Can you please point me to it again? Paul
Attachment:
signature.asc
Description: OpenPGP digital signature