1 |
[reordered to ease replying] |
2 |
|
3 |
Rich Freeman <rich0@g.o> writes: |
4 |
> Now, perhaps a more balanced approach might be to mask it and give 15 |
5 |
> days notice on -dev, and then it can be unmasked. Anybody who cares |
6 |
> about the library can test the new version, and if necessary update |
7 |
> their dependencies to use the previous slot only (and if 15 days isn't |
8 |
> enough time they can just update the dep right away and then update it |
9 |
> again after they get around to testing it). Those who don't want to |
10 |
> have to deal with that can just define their slot dependencies |
11 |
> explicitly so that this policy will never apply to them. |
12 |
|
13 |
Good idea! |
14 |
|
15 |
> The problem with this is that it puts the onus on the person who wants |
16 |
> to make forward progress (adding support for a new library version). |
17 |
> That means that they have incentive to either not bother with the new |
18 |
> library version (causing Gentoo to stagnate), or use hacks like giving |
19 |
> the library a new name (which we have examples in the tree of). |
20 |
|
21 |
> In order for a QA policy to be effective it has to either be minimally |
22 |
> intrusive, or make the cost of compliance lower than the cost of |
23 |
> workarounds or benign neglect. People don't HAVE to maintain |
24 |
> packages, after all... |
25 |
|
26 |
I agree with that. We are all aware that every gcc slot bump costs so |
27 |
much work (and frustration). |
28 |
|
29 |
At the same time, it worth the hard work for a well-organized tree and |
30 |
flexibility. |
31 |
|
32 |
The only draw back is lack of man power to do it right like bug |
33 |
493652. Yes, when a library introduces a new not fully compatible |
34 |
version, it naturally implies a lots of work to do for downstream like |
35 |
us. There is no escape: If we hack a versioned library name, it will |
36 |
bite us in the future. The question becomes: Who should do this heavy |
37 |
lifting? |
38 |
|
39 |
This is a glitch in the amount of work needed when a single-slotted |
40 |
library suddenly becomes slotted. IMHO, let's form a slotting group in |
41 |
the reformed QA team who will donate manpower for such situation to aid |
42 |
the library maintainer. Anyone who wants to make forward progress but |
43 |
does not have enough time seeks help to the slotting group. |
44 |
|
45 |
What do you say? |
46 |
|
47 |
Benda |