Hi.
I'm sorry it has taken a while to write back to you. I asked how the TC could help and was confused when I read your message. I provided a couple of options how we might be able to help and you neither selected one of my options nor provided your own. So, I wasn't sure what you were looking for. I've done my best and I hope that this helps you understand what's going on. I've decided to give my analysis of someone on the release team might reject your unblock request. This may not be the actual reason the release team (RT) acted as they did. I've never been on the RT, but I have taken on a similar role for other much smaller projects. I got input from other members of the TC in preparing this response, but these words are my own and this definitely doesn't represent a statement From the TC as a whole. In doing that I've read #771208 but not the other bugs. If I were on the RT and processing your unblock, I'd read the full unblock bug, and read enough of the referenced bugs to understand briefly the technical issue, but perhaps not enough to understand why someone thought they were important. This is an issue where I think reasonable people might disagree. I don't actually know which decision I would take were I on the RT; it would depend on the tradeoffs I'll discuss below. I appreciate that busybox-static is important to you. It's something you've worked on a lot, it's something you use and depend on. However, busybox-static is not as important to the project as a whole as busybox. Busybox-static is one of several debugging/recovery tools. We also have live DVDs, bootable media, alternate chroots/volumes to boot from. We could release with an entirely broken busybox-static. we cannot release with a busybox that is broken in a manner that breaks D-i, initramfs, etc. You claim that the changes do not affect the resulting binaries. Based on your analysis, you claim that if the busybox source package builds at all, your changes cannot affect whether the main busybox binaries function. However, the RT is likely to care as much or more about whether something builds as whether there is some bug introduced into the binary. Having core packages that build all the time, whenever you make a change to them, whenever you make an NMU, whenever you make a security fix is one of the highest priorities of doing release engineering for a large project. During the freeze, if I had to pick between a busybox that build all the time but sometimes produced a broken busybox-static and a busybox that sometimes failed to build because it could not produce a busybox-static I'd pick the potentially broken busybox-static. being unable to build a package when you need to make some change blocks forward progress. It can also cascade and affect forward progress on other packages. Changing the conditions under which a package will successfully build frequently has unexpected consequences. We might find people trying to build d-i in their own build environments face breakage because their libc is not up-to-date. That again can break things for people doing various kind of automated product builds and automated testing based on what's supposed to be a frozen release. I might be willing to accept the change if I were convinced that it would not break things for Debian. However, according to your mail you were running into cases where the buildds were not up-to-date. There is of course a counter argument, and it's the argument that I'd use if I were to decide to accept the change. It's frustrated to have a build that sometimes produces valid output and sometimes doesn't. Every few times when we do a security upload we'd run into a case where busybox-static is broken. And so we'd have to do yet another bin-nmu to fix it. That's frustrating in its own way. You claimed that the patch was easy to review, and that it obviously didn't change the binaries for busybox. I did a review of the unblock, and i didn't find the patch particularly easy to review, nor was I able to prove without doing a bit more work that it failed to affect the binaries for busybox. The RT has a bunch of stuff on their plate. If an unblock is not obvious and the decision is questionable it's more likely to be rejected. The mail you wrote to the TC, particularly the technical summary was really well done. If the unblock hedar looked a lot like that mail, I would have been more likely to accept the change had I been making the decision. Here are areas that concerned me when reviewing the unblock: * You talk about how multiple iterations were required and how this breaks hurd. In general, I have found that these sort of build changes are very tricky to get right and do tend to have unexpected consequences. You let me know that it took you a while to get this one to a point where you believe it is right, and even that has broken one thing that you know of. You would be better off spending at least as much space explaining the problems you ran into as explaining why you're 100% sure that there aren't additional things you've missed. You say that you've got it right now, but you never explain why that's true. If you made a mistake before, how come you're sure you're not making a mistake now. Build problems don't always result in fails-to-build. Are we going to get into a situation where a new libc upload creates problems? (I'm fairly sure no, but I'd expect an argument explaining why given that you went multiple rounds with the build-deps). Is there some chance we'll have problems with sometimes flakey static support and another platform besides hurd? * The changes to avoid building binary packages in arch indep make it hard to confirm you don't change the busybox binaries. I'd need to reconfirm that the same set of debhelper calls get called in the old rules and new rules. That's more effort than I'd be willing to spend for fixing that lintian bug. * The correctness of the generation of built-using is not obvious to me. It also seemed like it was a new approach for you, so I'd expect a longer explanation of why that's guaranteed to produce correct results. * Your unblock would have been significantly improved if you mentioned that you were running into ongoing problems with the unstable buildds and that the build-depend changes and static test would actually guarantee that we produced working busybox-static and without this we were having trouble doing so. Expecting this to fall out of the other bugs is not as good as explicitly mentioning it in the unblock. Again, your mail to the TC did adress some of these issues. Also, my point is not that I can't figure out the answers to these questions. It's simply that if these sorts of answers are more obvious From the unblock it's more likely to get favorable treatment. In the future if you find yourself in a similar position please consider an option like the following. "Hi. I don't think I can do a good job of maintaining this in jessie because I'm concerned that when the package is NMUed it will sometimes produce broken busybox-static. Since you won't accept the change, will you take responsibility for monitoring busybox-static and getting it correctly rebuilt when it breaks?" That is, if someone is putting you in a position where something is hard, rather than walking away from the entire package, ask them to take on responsibility for what they are complicating. I hope this helps you understand why someone in an RT role might have made a decision different than what you were hoping for. Your work is Debian is valued and I do hope that you find activities you're happy to get involved in within the project.
pgpPSF8_iiCXC.pgp
Description: PGP signature
