1 |
On Sun, Dec 8, 2013 at 9:37 PM, <heroxbd@g.o> wrote: |
2 |
> |
3 |
> How about defining a QA workflow for introducing a new slot of a |
4 |
> library, such as "mask it and open a tracker bug until every individual |
5 |
> reverse dependencies are checked"? |
6 |
> |
7 |
|
8 |
The problem with this is that it puts the onus on the person who wants |
9 |
to make forward progress (adding support for a new library version). |
10 |
That means that they have incentive to either not bother with the new |
11 |
library version (causing Gentoo to stagnate), or use hacks like giving |
12 |
the library a new name (which we have examples in the tree of). |
13 |
|
14 |
Now, perhaps a more balanced approach might be to mask it and give 15 |
15 |
days notice on -dev, and then it can be unmasked. Anybody who cares |
16 |
about the library can test the new version, and if necessary update |
17 |
their dependencies to use the previous slot only (and if 15 days isn't |
18 |
enough time they can just update the dep right away and then update it |
19 |
again after they get around to testing it). Those who don't want to |
20 |
have to deal with that can just define their slot dependencies |
21 |
explicitly so that this policy will never apply to them. |
22 |
|
23 |
In order for a QA policy to be effective it has to either be minimally |
24 |
intrusive, or make the cost of compliance lower than the cost of |
25 |
workarounds or benign neglect. People don't HAVE to maintain |
26 |
packages, after all... |
27 |
|
28 |
Rich |