[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 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.

Attachment: pgpXKVptCnsaC.pgp
Description: PGP signature


Reply to: