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