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

Re: Multiarch support in dpkg — really in time for wheezy?



[ Replying to this now, because it appears some people seem to think
  mails that go unanswered are considered as accepted facts... ]

On Sat, 2011-10-29 at 13:10:47 +0200, Stefano Zacchiroli wrote:
> [ Disclaimer: my only data points come from people who have been trying
>   to get m-a in the archive in the past several months, including the
>   Release Team and Raphael. I might hence be biased or misinformed.

I'd think so, yes.

> What worries me is that there is multi-arch work in dpkg, work that has
> its origins in Debian. That work is ready enough to be deployed in
> popular Debian derivatives such as Ubuntu, [...]

I don't particularly care what Ubuntu considers ready or not, but as a
practical example a dpkg with a brokenly designed on-disk db layout was
rushed out into Ubuntu, which I pointed out to them while I was doing
code review, and they had to handle the mess after that. It's also
going to be interesting what they'll need to do to handle the now
fixed interfaces and similar...

> That is bad for Debian morale and should be avoided. Moreover, that
> work is also considered ready enough by other dpkg co-maintainers, by
> the Release Team, and by various porters, which have all asked multiple
> times to have that work in the Debian archive.

Claims by people who during all this time, when this has supposedly been
considered such a priority and so important to the point of bringing
it to a confrontational body like the tech-ctte, have been either
unable or unwilling to review that code and find the problems it had.
I still have to see a single code review on the list...

> Accepting this attitude would be very bad for Debian, because it is at
> stake with the way we usually do things (AKA "do-ocracy"). Accepting
> this attitude would indeed mean acknowledging that people who have
> earned respect in the past as maintainers can stall work done by others
> by simply saying "NACK", without having to contribute alternative
> solutions and/or show progress. We cannot allow that to happen in
> Debian.

You keep mentioning this ralatively new “Debian is a do-ocracy” (which
I think it's been promoted mostly by you?) when it seems to me the
commonly held motto has always been “Debian is a meritocracy”. In any
case, more often than not whenever I've seen that being used, it seems
like an excuse to justify unsound technical decisions, or poor work.
And that's not really the Debian project I joined, which used to pride
itself for its technical excellence...

And if that attitude is not acceptable for Debian, then to me that means
Debian is not the correct place where to have upstream development
happening, because merging unsound unreviewed code is well, not
acceptable.

> [...] (And TBH the thought of you hurrying up
> now in doing such a work is worrisome in its own right.)

So, you mean that doing code review and cleanup is worse than not doing
any at all... ok.

> Please be a team player. If you can make it, that's great, we will all
> benefit from extra eyes on the code, especially if they are experienced
> eyes as yours. But if you cannot make it, please step back and allow for
> uploads to happen. In case you are not willing to do that, I'd be in
> favor of having other dpkg co-maintainers doing the uploads the Release
> Team is asking for. After all, there is nothing that cannot be fixed
> later in subsequent uploads.

If rushing things out and being sloppy or merging technically unsound
code is being a team player, then count me out. Also who do you think
would have had to cleanup that code afterwards anyway, if it had been
merged as it was at the time? (no one else has either been able or
willing to do it up to now...)

guillem


Reply to: