Re: Last hints for d-i, upload tomorrow
27.01.2015 08:59, Christian PERRIER пишет:
> (CC'ed in case you guys subscribed to -release. I am subscribed
> so please no CC)
>
> Quoting Michael Tokarev (mjt@tls.msk.ru):
>
>> So you're continuing to ruin my (hard in this case) work, spreading lies
>> (invasive) and confirming you're against others working on debian.
>
> Given that Cyril is THE person that currently makes Debian Installer
> to happen, I would kindly ask you to refrain on such claims, please.
Yes, I understand full well Cyril's role in the D-I, and I apprecate
it and I'm grateful for that. Really. However in this very case, I
told exactly what I think and feel. And I stand on my words, because
I think it is true and I'm not quite ready to lie yet. Maybe the same
can be expressed differently and worded better.
Also, the changes in question has nothing to do with the D-I itself,
these are minor changes in packaging and build process which result
in the same binary as used by d-i previously. So judjing here with
D-I hat on is not exactly wise, because the changes don't affect
D-I.
> You may have disagreements (which I don't share) but please keep the
> tone low and polite.
> We have a good release manager for D-I and, believe me, this is hard
> to find and you probably don't imagine the hard work he has for every
> release. For people who follow Debian closely, they probably noticed
> that Cyril obviously went through hard times recently and I felt some
> kind of demotivation in his mails, sometimes. I would prefer that
> nobody pushes harder in that direction.
Agreed 100%.
> So, well, your work on busybox is very highly appreciated and
> valued. Yes, it was in a bad state and you definitely revived
> it. We're all deeply thankful for that.
>
>> That's fine with me too. I can continue maintain local copy of busybox
>> the same way as I did before I took over its maintenance, because in
>> debian it was in *awful* state and mostly unusable.
>>
>> (For the record: all the recent changes I made in busybox is needed for jessie,
>> I especially and carefully selected the minimal set. We had it in broken state
>> for too long.)
>
> If these changes are needed for jessie, please follow the Debian
> release managers guidelines : point which release critical bugs are
> fixed by these fixes, and aruge with the Release Team about unblocks
> by providing patches (or just copy/pasting them from git) so that one
> release manager can make his|her own decision, with the help of
> Cyril.
That's the exact procedure I followed, after missing the deadline by a
few days because I was ill myself, and after a long delay dealing with
the static link issue in glibc (#769190). The RC bug has been filed
exactly due to that issue with static linking (#768876), so, being ill
myself, I rushed to fix it to ensure we wont have the same problem
again somewhere else during jessie lifecycle, thinking it is really
essential to fix it for jessie. Yes, #768876 is tagged jessie-ignore,
but that was just because Aurelien didn't want to add a "hard" (as it
turned out) bug before freeze. And yes it took me several iterations
to finally fix it for real.
Now, the only questionable difference between testing and what I think
must be in testing is this adding of Built-Using field for busybox-static
(which does not affect d-i in any way as I mentioned before), and minor
changes to the build procedure to stop building arch-all package when
only arch-specific build is requested - again, does not affect d-i.
While the build changes (arch-all vs arch-specific) aren't exactly
essential (it was trivial to fix, I was just tired stumbling upon
dpkg warning when rebuilding the package while trying to fix #768876),
#768876 itself is essential, well-tested finally, and simple. Yet
these (packaging-only) changes are being rejected, and I yet to see
a reason for that.
And while doing that, maintainer (me) is being pissed off and discoraged
from even thinking to work on this package again, *and* much more work
is being done to cherry-pick the "really-really-necessary" changes to
fix stupid bugs which are unimportant (because busybox isn't used in
debian in environments where these bugs can be triggered).
This is unfair and even stupid thing to do, because it is a way to
have more work to undo the _necessary_ things and to redo them again
in favour of things which actually aren't important. Why do more
when we already have enough and the work is already done??
> If that doesn't happen, then you can't hardly complain. Yes that may
> be a PITA work to do because this is indeed really a mandatory
> step. This indeed explains why important changes are better done
> *before* freezes than during freezes. And, yes, sometimes, the timing
> is not so good, given that all upstreams have their own schedule that
> doesn't fit Debian's. But we have to live with that.
Thanks,
/mjt
Reply to: