Re: bastardizing packages or stepping down
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
Re: bastardizing packages or stepping down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 06.03.2015 15:02, Sam Hartman wrote: [] So, you're involving the TC because you're hoping to better understand why your unblock was not approved? How are you hoping the TC can help? Here are some options I see: * Some folks on the TC are fairly good at release engineering and have been involved in this either in Debian, for other projects or for other distributions. We could look over the situation and try to help you understand why someone might decide not to approve those unblocks. Since we weren't the one acting on the request we can give you an understanding of why someone might think that way, but not why they did. * Alternatively you could be asking for help engaging with the release team and Cyril to explain the actual reasoning involved. Or perhaps you're asking for something else. I asked for understanding mostly. But as I wrote at the very beginning of my first email, I don't have much hope. This email has been sent to 3 places: d-i team who rejected busybox, d-release team and TC, so maybe at least one party can find something to say or do. What I see here are 3 possible solutions to this problem. I guess I ordered them right, starting with most unlikely but best, and ending in most likely but worst. a) allow current busybox to migrate from unstable to testing. This is what I asked when filing an unblock-udeb request initially in #771208, which was filed before jessie freeze. This is what will make everyone happy, I think, including current people involved with the package because there wont be any reason anymore to do the same work twice (including making another crippled release for jessie with unneeded-for-debian security bugfix but without needed- for-jessie other fixes), there wont be any need anymore to bastardize the package. Disadvantages are none, to my view anyway, except that in this case, people who rejected the unblock request will have to agree it was a mistake. That, I think, is one of important points here, because Cyril is one of them (if not the only one), and he's an important person for the project, and no one want to make him unhappy. But since this hasn't happened so far, and even my main questions went unanswered this far in the release cycle, I've no hope for this. b) someone -- be it TC, or D-I team, or the Release team, explain to me why the changes hasn't been accepted. I asked this several times, but always got the same answer: the changes are fixing jessie-ignore bug and introduce uneeded-for-jessie changes for things which are now history already (glibc bug). To which I answered initially in the very first unblock request: the jessie-ignore thing was only because that bug was _difficult_ to fix in time for jessie (but I did that and I was in time), so not to introduce an RC bug which is unlikely to be fixed, and that these changes are _needed_ for jessie, not anything past jessie, exactly because it isn't yet history for jessie, as buildd story demonstrates, and because fixed glibc hasn't even been released upstream at the time -- if not for jessie users, this helps derived distributions and in other situations, like backporting and whatnot. But even more: all this, which I voluntary explained, is hardly relevant for the unblock-UDEB request, because none of the changes in question EVER affect D-I in any way whatsoever. So I don't really understand why an unblock-UDEB request has been denied in a background that the changes aren't needed for jessie, BEFORE jessie has been frozen? And another question which I asked several times is, even if the changes aren't exactly necessary, does it HURT any? Does the new stuff break anything? If not, again, why to work more when it's that simple to do less and make everyone happy? So, basically, it'd be good to understand why. Maybe TC can help, maybe the release team can, or maybe d-i team, I dunno. c) lacking a) and b), I don't have any choice but to step down. The reason is plain and simple. I don't understand why, see b), why even such small, easy to review, carefully selected, tested and needed changes can't be accepted, and why my questions goes on unanswered while freeze progresses, and why it is better to do more work _instead_ of the same work which I already did. Since I don't understand why my work isn't needed for debian, and instead, debian prefers to do MORE work, I see this as I'm not helping debian but instead disturbing its work. So I can't continue, I don't want to make life for others harder. So I _have_ to go. I can't even change the way I do things to make it easier for debian, because I don't understand what is going on so don't know the direction to change myself. So, if c) is the only choice I have, I request that my name be removed from all packages which, at leaat, produces udebs (these are busybox and mdadm so far) on the next upload, and I'm stopping maintaining these packages, because I don't
Re: bastardizing packages or stepping down
However, I still really want to understand that unknown reason why all this happened, why it is so difficult to accept a working package than to do more bastardizing work, why it is smart to reject good stuff and to do absolutely unnecessary work (double work with maintaining 2 version and applying patches wchich aren't needed for debian as a whole, not only for jessie). This is the reason I'm Cc'ing ctte@, but without much hope really, due to already mentioned reason. Hi. So, you're involving the TC because you're hoping to better understand why your unblock was not approved? How are you hoping the TC can help? Here are some options I see: * Some folks on the TC are fairly goodat release engineering and have been involved in this either in Debian, for other projects or for other distributions. We could look over the situation and try to help you understand why someone might decide not to approve those unblocks. Since we weren't the one acting on the request we can give you an understanding of why someone might think that way, but not why they did. * Alternatively you could be asking for help engaging with the release team and Cyril to explain the actual reasoning involved. Or perhaps you're asking for something else. Thanks for helping me understand what you're hoping the TC can provide. Sam, who is not currently on the TC, but seems headed in that direction when paperwork clears. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014beef77d19-5cd761ec-20c8-4442-a379-2136c8732672-000...@email.amazonses.com
Re: bastardizing packages or stepping down
On Thu, Mar 05, 2015 at 01:38:29PM +0300, Michael Tokarev wrote: But once I uploaded a next release of busybox to the archive, it was rebuilt using older, unfixed glibc, and the original problem reappeared. I didn't see any request to make sure the chroots are updated. Not having read the whole thing, would this solve your problem? Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150306094626.ga32...@roeckx.be
Re: bastardizing packages or stepping down
Hi, Making no comment on the remainder of the mail: On 2015-03-05 10:38, Michael Tokarev wrote: And since I can't do my work, I'm stepping down from being busybox maintainer, and am kindly asking the release team to remove my name from debian/control file in busybox, so that people don't blame me for things I can't do. I don't believe it would be appropriate for us to do so. We have no control or say in who maintains packages (beyond that available to any other DD or interested contributor). Regards, Adam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3096c5baa7a53b477a9cf7fb151e7...@mail.adsl.funky-badger.org
Re: bastardizing packages or stepping down
Hi, Bah, so much for a quick response that I thought was simple and uncontroversial. :-) On 2015-03-05 12:08, Sam Hartman wrote: Adam, let's assume for the moment I've got that right. I'm trying to connect with the frustration I'd feel if I were told that I didn't even have the power to distance myself from something I couldn't in good conscious claim to support. I hope that there's some way that michael can approach stepping away from the package in jessie if he wants to. If what you're saying is that his proposed mechanism for doing that is the wrong one, would you be willing to help him out and suggest a mechanism you believe to be more appropriate? Yes, I'm specifically saying that I don't believe the Release Team has the authority to do what Michael is asking of us, nor do I believe we should do so. (Individual DDs who are part of the team can of course do so. Apologies if this seems like splitting hairs, but I think the distinction is important.) The way I'd expect a voluntary change of maintainership to be made would be via an upload either by the existing maintainer, another member of the maintainer team (where appropriate) or the new maintainer (or I guess $RANDOMDD as a QA upload with maintainer's consent or similar). I'm certainly not saying that Michael shouldn't be able to remove himself, simply that I'd feel uncomfortable with the Release Team as an entity doing so. (Perhaps you'd approve an ublock for an upload that simply changed maintainer to debian-qa?) For the record, the Maintainer: listed in the package is debian-boot; Michael's in Uploaders. If it's really that much of an issue then I imagine they could be persuaded to remove his name from the package and in that case I can't see that getting it migrated under those circumstances would be a huge problem. If what you're saying is that you see no mechanism for him to step away from a package he no longer feels he can maintain because he and the release team disagree with the desired contents of that package in Jessie I'm not sure the Release Team has expressed any particular opinion on the desired contents of the package beyond deferring to the d-i RM. I admit that I haven't gone back and checked through the full history of the unblock requests though, so I may have missed something. Regards, Adam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/31296833bbe23bf2ae79747b8b488...@mail.adsl.funky-badger.org
Re: bastardizing packages or stepping down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 05.03.2015 15:08, Sam Hartman wrote: Adam == Adam D Barratt a...@adam-barratt.org.uk writes: Adam Hi, Making no comment on the remainder of the mail: Adam On 2015-03-05 10:38, Michael Tokarev wrote: And since I can't do my work, I'm stepping down from being busybox maintainer, and am kindly asking the release team to remove my name from debian/control file in busybox, so that people don't blame me for things I can't do. Adam I don't believe it would be appropriate for us to do so. We Adam have no control or say in who maintains packages (beyond that Adam available to any other DD or interested contributor). michael, I'd like to ask if I'm hearing you correctly. So, what I'm hearing is very strong frustration. You had hoped that you would have the power to produce a package that you'd be happy being responsible for. However you don't believe that you have that power; you're saying that changes you consider essential to creating a busybox you're comfortable being responsible for are rejected. Am I hearing you correctly? Well. It is not about being happy or being powerful. It is about at least understanding the reasons why we should take bad and have more work instead of taking good and have peace. This is the main source of frustration, and this is the main question which went unanswered so far. The main changes I've made (this build-using thing plus a build-time glibc check) are _only_ needed for jessie, since after jessie this whole single issue will really be history, while for jessie it isn't history yet, like a story with buildds demonstrating. Another source of frustration is the fact that all the changes in question does not break things, it does not hurt anyone, and especially does not affect the D-I in any way whatsoever, but are being rejected on the D-I side. Another frustration comes because much more intrusive but much less needed changes are being happily accepted after the deadlines, even if here, I missed the deadlines because of factors not under my control, but trying my best. So, the main point is that apparently it is better to do more work and make everyone frustrated than to just accept already (hopefully well-) done work and continue peacfully. I don't see the reason WHY (hence I Cc'd ctte). It is not about power. Adam, let's assume for the moment I've got that right. I'm trying to connect with the frustration I'd feel if I were told that I didn't even have the power to distance myself from something I couldn't in good conscious claim to support. I hope that there's some way that michael can approach stepping away from the package in jessie if he wants to. If what you're saying is that his proposed mechanism for doing that is the wrong one, would you be willing to help him out and suggest a mechanism you believe to be more appropriate? (Perhaps you'd approve an ublock for an upload that simply changed maintainer to debian-qa?) There's no need to change maintainer, it is debian-boot (d-i team) and it remains like that, at least in busybox. In busybox my name is in Uploaders: field only. For mdadm, on the other hand, even if it is set as team-maintained, the sole maintainer is me, so that'd be appropriate to change maintainer to debian-qa. Both packages affects d-i, and for the reasons I already described, I can't do that myself, since I'll face the same unblock request process from the D-I team. More, I don't really want to keep my name as the author of last changelog entry in this case. If what you're saying is that you see no mechanism for him to step away from a package he no longer feels he can maintain because he and the release team disagree with the desired contents of that package in Jessie, then I respectfully ask you to reconsider that position. That sort of thing would likely drive me away from the entire project, not just one package. Actually this was my first reaction, but I thought I'd wait for a bit and just point out a possible defect in debian, possible request for discussion. Micahel, one final question to you. Are you firmly committed to the path of stepping away from busybox maintenance, or would you be willing to re-evaluate that decision after we see what comes of your request for understanding? I don't believe there's any other alternative actually. I dunno, it is difficult to think. I wanted to understand the WHY first, because clearly, as I tried to describe, I don't see, at all, why this is done. I don't really feel powerless, that's not the problem, after all no single person should have absolute powers (including Cyril, no matter how respectful I or anyone else is for him due to his work). After all I always have absolute power to continue maintaining the package locally, and that's what I definitely will do, because I depend on it and I don't want it to become in that really bad shape it was before me. But so
bastardizing packages or stepping down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I didn't really want to write this email, but it looks I now have to, even if, for reasons which whill be shown below, don't expect any good news from this. Trying to make the story short. For quite some time we had a bug in glibc in jessie which resulted in statically-linked applications malfunctioning when using any of nsswitch-related functionality (eg gethostbyname() etc), #757941. This glibc bug resulted in bugreport about busybox package -- #769190 (#757941 has been filed against busybox too, initially). The problem was that many busybox applets didn't work in static build. That bug was rather fun, because even if it is fixed in glibc, your package depends on the fixed version to be present on all buildds, or else the resulting binary will be buggy again. This is exactly what happened with #769190 -- to work around initial #757941 in bb, it has been bin-NMUed and rebuilt with a fixed glibc. But once I uploaded a next release of busybox to the archive, it was rebuilt using older, unfixed glibc, and the original problem reappeared. For added fun, since glibc package names are architecture-dependent, it is rather difficult to express all necessary build-depends correctly. Having all this, and having in mind that at least initially you don't know if this particular build of your package is affected or not, another bug has been filed against busybox -- #768876, requesting that busybox-static have a Built-Using field to allow seeing which glibc version it was built against, at least. This bugreport (#768876, built-using) is of serious severity and is tagged with jessie-ignore, not because it is irrelevant for jessie but because it is _difficult_ to fix and the package already received manual treatment to be rebuilt against a fixed glibc version. Understanding the actual severity of this problem, I tried to fix this before jessie, because I know it is important to do so (see below). I had fever at that time, and fixing it turned out rather difficult and required several iterations to finally get it right. I especially tried to fix that as fast as possible despite the fever, because it was near jessie freeze so, even if I was absolutely sure it wont be a problem to accept these changes to jessie, I didn't want to add more work for already busy enough release team to review and accept the changes. But at that time things didn't go right, because it turned out many buildds are still having old version of glibc and the resulting binary is buggy again. So I tried to add a versioned build-dependency on glibc, which too took several iterations because glibc package names are arch-specific and because I wanted to keep ability of busybox to be compiled against old version of glibc (eg for backports), both of which finally worked. Also I added a built-time test which builds a tiny static program which does getpwnam(root), to verify before build that the build environment is able to produce static executables at all. At least this should ensure we wont have known-broken binary after a successful build. All 3 changes -- the generation of Built-Using field, the build-time test to ensure static linking works, and addition of extra build-depends field -- are small and self-contained in d/rules (or d/control) file, easy to review or remove when it all really becomes history. Meanwhile I fixed another, unrelated, buglet in the package which annoyed me enough during these multiple uploads -- I changed d/rules so it does not produce arch-all package (busybox-syslogd) when asked only to produce arch-specific packages. This was a bit larger change in d/rules but is a well tested in other packages. Neither of these changes, and this is important point, -- neither of these changes affects the resulting binary packages on a system where glibc is fixed. The changes adds one extra field (Built-Using) to busybox-static package, ensures the build environment is able to produce a static binary and introduces a versioned build-depends on libc which allows us to build the package either with fixed glibc version or with glibc which does not have that bug yet. After all this it turned out that several buildds were still having issues with the new build-depends, so the package were attempted to build multiple times - some buildds had unfixed glibc so build-depends were impossible to satisfy. More, it turned out hurd-i386 build env is not able to produce a working statically-linked getpwnam(root) binary at all. So I pinged buildd maintainers asking to update glibc, I also contacted hurd people asking what to do (hurd is not a release arch but it is in buildd and if I can fix hurd before freeze so I wont need to add more work for the release team that'd be nice). But time was, ofcourse, ticking. (Btw, I received no replies to my inquires about release-goal buildds, however after numerous attempts buildd network finally was able to produce working busybox
Re: bastardizing packages or stepping down
Adam == Adam D Barratt a...@adam-barratt.org.uk writes: Adam Hi, Making no comment on the remainder of the mail: Adam On 2015-03-05 10:38, Michael Tokarev wrote: And since I can't do my work, I'm stepping down from being busybox maintainer, and am kindly asking the release team to remove my name from debian/control file in busybox, so that people don't blame me for things I can't do. Adam I don't believe it would be appropriate for us to do so. We Adam have no control or say in who maintains packages (beyond that Adam available to any other DD or interested contributor). michael, I'd like to ask if I'm hearing you correctly. So, what I'm hearing is very strong frustration. You had hoped that you would have the power to produce a package that you'd be happy being responsible for. However you don't believe that you have that power; you're saying that changes you consider essential to creating a busybox you're comfortable being responsible for are rejected. Am I hearing you correctly? Adam, let's assume for the moment I've got that right. I'm trying to connect with the frustration I'd feel if I were told that I didn't even have the power to distance myself from something I couldn't in good conscious claim to support. I hope that there's some way that michael can approach stepping away from the package in jessie if he wants to. If what you're saying is that his proposed mechanism for doing that is the wrong one, would you be willing to help him out and suggest a mechanism you believe to be more appropriate? (Perhaps you'd approve an ublock for an upload that simply changed maintainer to debian-qa?) If what you're saying is that you see no mechanism for him to step away from a package he no longer feels he can maintain because he and the release team disagree with the desired contents of that package in Jessie, then I respectfully ask you to reconsider that position. That sort of thing would likely drive me away from the entire project, not just one package. Micahel, one final question to you. Are you firmly committed to the path of stepping away from busybox maintenance, or would you be willing to re-evaluate that decision after we see what comes of your request for understanding? thanks for your consideration, --Sam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014be9d67c2a-235bd750-20d6-4195-86ca-98841d13dc39-000...@email.amazonses.com
