1 |
On Thu, Oct 24, 2013 at 12:28 PM, Jeroen Roovers <jer@g.o> wrote: |
2 |
> Keyword requests that do not block stabilisation requests should be |
3 |
> requested by users of the specified architectures or should go |
4 |
> to /dev/null. Keyword requests that do block stabilisation requests |
5 |
> should get the same treatment as the stabilisation requests that they |
6 |
> block. How else would you resolve them? |
7 |
|
8 |
The situation causing issues is a different one. |
9 |
|
10 |
1. Tree contains libfoo-1. |
11 |
2. Maintainer introduces libfoo-2, dropping keywords due to |
12 |
significant changes. |
13 |
3. Major archs keyword libfoo-2. Tree is generally updated to work |
14 |
with libfoo-2. |
15 |
4. Maintainer wants to drop libfoo-1, but libfoo-2 is not keyworded |
16 |
on all the minor archs libfoo-1 is. |
17 |
5. Maintainer logs KEYWORDREQ for libfoo-1, and it is ignored. |
18 |
|
19 |
This leaves us with several options: |
20 |
a. Don't let the maintainer remove libfoo-1. |
21 |
1. Maintainer continues to care for libfoo-1 - extra work. |
22 |
2. Maintainer is required to care for libfoo-1 but doesn't - complaints/etc. |
23 |
3. Maintainer gets tired of dealing with QA and stops maintaining |
24 |
libfoo entirely. Now major arch users are at a loss, and the minor |
25 |
arch users are no better off. |
26 |
|
27 |
b. Let the maintainer remove libfoo-1. Minor arch users have large |
28 |
numbers of packages break, have cascading keyword removal (no better, |
29 |
really). |
30 |
|
31 |
I'm open to suggestions for other options if anybody has them. I'm |
32 |
suggesting to allow the option of b. Maintainers can still choose to |
33 |
do 1a, and minor arch users are really no worse off than if they were |
34 |
to do 1b/c. |
35 |
|
36 |
Rich |