Gentoo Archives: gentoo-dev

From: Jeroen Roovers <jer@g.o>
To: gentoo-dev@l.g.o
Subject: Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)
Date: Sun, 16 Feb 2014 14:46:34
Message-Id: 20140216154623.3fb500a7@marga.jer-c2.orkz.net
In Reply to: Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords) by Pacho Ramos
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

Replies