On Sunday 29 June 2008, Pierre Habouzit wrote: > I'm not the one that removed the package, and I don't know the > rationale behind this removal. How is that relevant? I really don't care if it was Tom, Dick or Harry who did the actual removal. From my perspective this removal was done by the release team, apparently following the release team policy. If you say that you don't work that way, then good for you! But if others within the team do not work to the same high standards, you will still have to accept that, as a team, you're held accountable for their work too. > > I'm very grateful to Adeodato for the work he's done on getting the > > "do not remove" functionality implemented, but it is extremely sad > > that that functionality is needed at all. IMO the fact that it _is_ > > needed says a lot about the quality of the current "release > > management" effort. > > You're sad that we don't (in the release team) know every single > internal piece of d-i ? No, I'm sad that the release team apparently feels it can rely on dumb scripts to do removals rather than to judge packages and BRs on their own merits, or to ask in case of doubt instead of just going forward. The addition of these lists for D-I means that there is now less chance that D-I will get "accidentally" broken, but I would guess there are plenty of other areas than D-I where harm can be done by uncritical removals of so-called "fringe" packages. > Well too bad then. I'm glad we have this in > place because now I don't have to worry about a mistake. But I assume > it's easier to be the jerk in the conversation, and completely overlook > the huge task that is doing a good job in the release team. Everyone > expect us to know every single bit of anything that makes Debian works, > and heellooo we don't, because no one humanly can. So we need help. And > yes, the fact that we develop these tools says a lot about the release > management: we care. I think I can safely say that I do know what a huge job RM is as I've been rather closely involved in both the Sarge and Etch releases. I also know that the approach taken by and general attitude of the current RMs is significantly different from that of RMs during previous releases. What I expect of RMs is that you _talk_ to your fellow DDs before fucking with *their* work on which they also spend huge amounts of *their* time. The fact that your job is big is no excuse for treating the work of others lightly. If you _had_ posted lists of "packages we're thinking of removing because of RC bugs" to e.g. d-devel (as Steve suggests), you can be sure that someone from the D-I team would have spoken up if those lists contain loop-aes or lilo. And probably someone else would have spoken up about resolvconf. And you'd probably have gotten good reasons why those packages should not be removed, and that discussion would probably have resulted in help with fixing the bugs too. And all without the cost of flamewars after the fact. And, miracle of miracles, there would have been NO NEED for the tools dato has now developed... The only way you get help is by *asking* for it; and if people are not responding then there is probably something wrong with the way you are asking. It's absolutely clear that the release team cannot fix every bug themselves, nor can you write the release notes or update the whole website all by yourselves. However, if you're going to continue to piss off other developers or ignore those facets of a release, you can be sure you'll end up having to do just that.
Attachment:
signature.asc
Description: This is a digitally signed message part.