Gentoo Archives: gentoo-dev

From: Chris White <chriswhite@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [Summary] tentative x86 arch team glep
Date: Tue, 06 Sep 2005 10:37:06
1 Yet another thread that's getting horrificly long, here comes your summary
2 folks:
4 Introduction
6 An email was sent by Grant Goodyear containing a GLEP for the official x86
7 arch team establishment [1].
9 Discussions
11 Ciaran McCreesh requested more information on exactly what the line:
13 There will be a considerable one-time cost involved in establishing a
14 robust x86 arch team.
16 Stated. Grant stated the following:
18 * Although x86 arch recruitment is currently underway, I suspect that
19 we will need notably more devs to be x86 arch devs than we currently
20 have signed up. (I don't know how many arch devs amd64 have, but I
21 assume a similar number would be needed.) I assume that the x86 will
22 want non-dev arch-testers as well, and all of that will have to be
23 set up.
24 * Having bodies on x86 <at> is just the starting point. The
25 more difficult part will be convincing people that it is in their
26 best interests to do things this way. Similarly, what do we do with
27 devs who refuse? All of those issues still remain to be worked out.
29 Stuart Herbert states the glep really addresses what problems it will be to
30 developers, but in actually it is what problems occur to the users.
32 Joshua Baergen states that maintainers need to notify arch teams about going
33 stable before a package meets its 30 day minimum stable requirement (without
34 any outstanding bugs).
36 Homer Parker states that some devs should have stable only system, some
37 testing, and some with chroots for package.mask testing.
39 bit o flames here
41 Jason Stubbs recommends that an overlay for ebuild devs to work on be created,
42 and arch team stuff goes to the main tree. Users could use gensync in order
43 to decide how fast paced they want their software model to go.
45 Mike Frysinger states that arch teams need contact with the maintainers before
46 going stable.
48 Grant Goodyear states that while this is true, arch teams need the final say,
49 because they know deal with the architecture aspect (ie. while maintainers
50 know the software, arch teams know the system).
52 Jason Wever states that while this is true, arch teams may need to stablize
53 something sooner if previous versions were broken.
55 Stuart Herbert recommends that a main keyword be created to mark packages as
56 ready for arch testing. This would increase communication between
57 maintainers and arch teams.
59 Ciaran McCreesh states that while it's a good idea for some packages, others
60 need arch maintainers to override (toolchain, kernel).
62 Stuart Herbert asks as to why maintainers need to be overrided instead of
63 communicated to directly.
65 Simon Stelling states that maintainers can vouch for their own arch, but it's
66 hard to tell another arch team how to handle their own system.
68 Grant Goodyear states that the arch teams need to intervine because they deal
69 with the entire tree and how packages relate to each other, rather than the
70 maintainer who deals with their own package. He also states the point of
71 this whole discussion was to seperate arch teams from package maintainers.
73 Diego Pettenò states that maintainers still need a way to suggest things be
74 marked stable.
76 Stuart Herbert states that the maint keyword is still needed for maintainers
77 to suggest something be marked for stable. He also agrees with something
78 similiar to what jstubbs requested regarding seperate packages and arch
79 trees.
81 Jason Wever states that he likes to keep the tree the way it is, but mentions
82 that arch maintainers stating that something (such as a scripting language)
83 may seem cross platform, but certain core elements of the language may have
84 broken architecture dependant code that causes it to crash. This is the
85 instance where arch maintainers would "know better".
87 Ciaran McCreesh states that some package maintainers violate QA policies and
88 need to be overriden by arch teams. He also brings up that candidates for
89 stable are already marked ~arch and that something that shouldn't be
90 considered for stable should be in package.mask.
92 Stuart Herbert states that package.mask is generally diffult to get supported
93 (ie. users won't readily file bug reports).
95 Daniel Goller asks if this means we're dumping untested work onto our users.
97 Stuart Herbert replies that this is not the case, and that users are the only
98 resource we really have for testing (ie. we lack test guidelines and tools).
99 He mentions PHP5 package.mask and seperate overlays, and that the seperate
100 overlays got more feedback than did package.mask-ing (as with things such as
101 Gentopia).
103 R Hill confirms this and states that package.mask seems to bring an unwanted
104 "we won't support this unless you provide patches" sort of approach, while
105 overlays are specifically made for the purpose and welcome any sort of
106 reporting.
108 Kevin F. Quinn states a list of things that the x86 arch team should compose
109 of (listed here [2] to keep this email shorter).
111 Ciaran McCreesh states that the ebuild quiz (point in [2]) is not difficult
112 and should still be kept that way.
114 Kevin F. Quinn states that the ebuild quiz is mainly oriented towards
115 developers as the audience, and is not recommended for users that are simply
116 told to "test a package and note the USE flag configuration, seeing what
117 happens".
119 Nathan L. Adams states that users need to work with both an ebuild quiz and a
120 qa testing quiz
122 Homer Parker states that an arch testing quiz is a good idea and mentions the
123 amd64 one centralized for QA and troubleshooting. He also notes that while
124 some arch testers become devs, some are simply content with arch testing.
126 Tom Martin mentions that the maintainer arch is valid, and that the current
127 policy is that no arch team should go past a maintainer in stable marking.
128 He also states that some packages are taken up by non-x86 maintainers and
129 don't have x86 keywording because of that. He also mentions that the x86
130 team should be small considering the number of packages that will be changed
131 as a result.
133 Nathan L. Adams states a policy should be created whereas maintainers have a
134 maint keyword, arch teams don't go past that, and they can optionally deal
135 with their own maintainer arch.
137 Ciaran McCreesh and Stuart Herbert agree that the x86 team needs to be
138 coordinated and a full arch team.
140 Daniel Goller mentions that if arch teams could not override some overly picky
141 package maitnainers, their powers would be very limited.
143 Stuart Herbert also states that arch maintainers can be somewhat overly picky
144 as well and that the problem comes from both sides. He then goes to state
145 that arch teams that override package maintainers should take on the burden
146 of support.
148 Ciaran McCreesh states that ~arch keywording is just for that purpose, and
149 that a maintainer shouldn't put something in ~arch if it's not stable
150 capable.
152 Some more discussion follows asking that ~arch be used as the stable ready
153 marker. It also is stated that ~arch is not about testing for a package
154 readiness, but more ebuild readiness.
156 [1]
157 [2]
159 Chris White
161 --
162 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] [Summary] tentative x86 arch team glep Mike Doty <kingtaco@g.o>
Re: [gentoo-dev] [Summary] tentative x86 arch team glep Ed W <lists@××××××××××.com>