2011/10/11 Chí-Thanh Christopher Nguyễn <chith...@gentoo.org>: > There was no indication 9 months ago that this bug is so bad that the > package would be removed if not fixed. Masking the package is ok if it > is totally broken or violates policy. Removal when the maintainer is > explicitly against it is not ok.
Agreed. I understand that sometimes major packages need to be upgraded, and when you have 350 out of 360 blockers resolved sometimes you have to just draw the line for the sake of the many. However, when you want to do this: 1. Announce the general initiative on -dev-announce if it is a big one so that people know it is happening. 2. Post in all the blocker bugs that on DATE you plan to mask the package to allow for the other package to move. Make DATE at least 30 days in advance. 3. When you do mask it, then just mask it, not for removal unless it is unmaintained (in which case refer to treecleaners). In this case some developer picks up a package in Aug and out of the blue it is masked for removal. Sure, there was a bug logged against it, but most of the packages in the tree have bugs logged against them and I wouldn't expect them to suddenly start disappearing. Finally, when you are taking action in some role (QA, whatever), make a note of it so that people know in what capacity you are acting and what project head to escalate to. If you can't say that "I'm doing this as a treecleaner with the project lead's blessing" or "I'm doing this as a member of QA with the QA lead's blessing" then you probably shouldn't be touching somebody else's package. The QA lead should be held accountable for things done by QA, but it is a bit hard to do it when people not in QA are just doing whatever they feel is best for QA in general. In general if you're going to be masking a whole bunch of packages for the sake of QA, then the QA lead should probably be aware that you're doing it. Rich
