1 |
On Sun, 16 Feb 2014 15:18:42 +0100 |
2 |
Pacho Ramos <pacho@g.o> wrote: |
3 |
|
4 |
> I think that, if they delete del old version without breaking the tree |
5 |
> (and, then, moving the package to testing for that arch), the |
6 |
> situation is improved. But, if the bug is assigned to the same team |
7 |
> that cannot handle its stabilization, I doubt they will move it to |
8 |
> testing either. |
9 |
|
10 |
And when you do break the tree when you threaten to effectively remove |
11 |
an arch keyword, then you may need to dig deeper and remove more |
12 |
keywords elsewhere until you've found an "unstable" solution. As long |
13 |
as you communicate the solution to that team, and maybe prod someone on |
14 |
IRC until they make the time to look at it and (reluctantly) agree, |
15 |
there should be no problem in dropping stable for them. |
16 |
|
17 |
> But, I guess there are two major cases: |
18 |
> - Versions that cannot be stabilized due they not working on that arch |
19 |
> any longer |
20 |
|
21 |
It's probably a good idea to package.mask the affected versions on the |
22 |
arch profile(s) (with references to bug reports, and so on) so all users |
23 |
of that profile get to see it. Treat it like a "last rites" process. |
24 |
Currently that's the only way for users to find out when and why a |
25 |
package becomes unsupported on a given profile, and it should work |
26 |
well enough. Give them thirty days to respond or become arch team |
27 |
members or ATs or just give the nod to an arch developer to say "it |
28 |
works" - it may even lead to actual stabilisation of a newer ebuild. |
29 |
|
30 |
> - Versions that are not stabilized because arch team doesn't have the |
31 |
> man power to do that. |
32 |
|
33 |
As above, package.mask would be a good intermediate solution, |
34 |
communicating the problem to the arch users for, say, thirty days. Of |
35 |
course it may just delay solving the problem when a new set of |
36 |
stabilisations is due and again no one responds. |
37 |
|
38 |
> I am referring to the second case that is also really common. This |
39 |
> also raises again the question about being enough to do build tests |
40 |
> for that arches or not. |
41 |
|
42 |
No, "compile only" is never enough to call something "stable". |
43 |
|
44 |
> If that is the case, would be nice if maintainers could have access |
45 |
> to that machines to let us help them :) (if I would build them on |
46 |
> that arches, I would try to help for sure) |
47 |
|
48 |
http://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Machines |
49 |
|
50 |
|
51 |
jer |