[gentoo-dev] [Summary] tentative x86 arch team glep

[Chris White]

Yet another thread that's getting horrificly long, here comes your summary 
folks:

Introduction

An email was sent by Grant Goodyear containing a GLEP for the official x86 
arch team establishment [1]. 

Discussions

Ciaran McCreesh requested more information on exactly what the line:

There will be a considerable one-time cost involved in establishing a 
robust x86 arch team.

Stated.  Grant stated the following:

*  Although x86 arch recruitment is currently underway, I suspect that
   we will need notably more devs to be x86 arch devs than we currently
   have signed up.  (I don't know how many arch devs amd64 have, but I
   assume a similar number would be needed.)  I assume that the x86 will
   want non-dev arch-testers as well, and all of that will have to be
   set up.
*  Having bodies on x86 <at> gentoo.org is just the starting point.  The 
   more difficult part will be convincing people that it is in their
   best interests to do things this way.  Similarly, what do we do with
   devs who refuse?  All of those issues still remain to be worked out.

Stuart Herbert states the glep really addresses what problems it will be to 
developers, but in actually it is what problems occur to the users.

Joshua Baergen states that maintainers need to notify arch teams about going 
stable before a package meets its 30 day minimum stable requirement (without 
any outstanding bugs).  

Homer Parker states that some devs should have stable only system, some 
testing, and some with chroots for package.mask testing.

bit o flames here

Jason Stubbs recommends that an overlay for ebuild devs to work on be created, 
and arch team stuff goes to the main tree.  Users could use gensync in order 
to decide how fast paced they want their software model to go.

Mike Frysinger states that arch teams need contact with the maintainers before 
going stable.

Grant Goodyear states that while this is true, arch teams need the final say, 
because they know deal with the architecture aspect (ie. while maintainers 
know the software, arch teams know the system).

Jason Wever states that while this is true, arch teams may need to stablize 
something sooner if previous versions were broken.

Stuart Herbert recommends that a main keyword be created to mark packages as 
ready for arch testing.  This would increase communication between 
maintainers and arch teams.

Ciaran McCreesh states that while it's a good idea for some packages, others 
need arch maintainers to override (toolchain, kernel).

Stuart Herbert asks as to why maintainers need to be overrided instead of 
communicated to directly.

Simon Stelling states that maintainers can vouch for their own arch, but it's 
hard to tell another arch team how to handle their own system.

Grant Goodyear states that the arch teams need to intervine because they deal 
with the entire tree and how packages relate to each other, rather than the 
maintainer who deals with their own package.  He also states the point of 
this whole discussion was to seperate arch teams from package maintainers.

Diego Pettenò states that maintainers still need a way to suggest things be 
marked stable.

Stuart Herbert states that the maint keyword is still needed for maintainers 
to suggest something be marked for stable.  He also agrees with something 
similiar to what jstubbs requested regarding seperate packages and arch 
trees.

Jason Wever states that he likes to keep the tree the way it is, but mentions 
that arch maintainers stating that something (such as a scripting language) 
may seem cross platform, but certain core elements of the language may have 
broken architecture dependant code that causes it to crash.  This is the 
instance where arch maintainers would "know better".

Ciaran McCreesh states that some package maintainers violate QA policies and 
need to be overriden by arch teams.  He also brings up that candidates for 
stable are already marked ~arch and that something that shouldn't be 
considered for stable should be in package.mask.

Stuart Herbert states that package.mask is generally diffult to get supported 
(ie. users won't readily file bug reports).

Daniel Goller asks if this means we're dumping untested work onto our users.

Stuart Herbert replies that this is not the case, and that users are the only 
resource we really have for testing (ie. we lack test guidelines and tools).  
He mentions PHP5 package.mask and seperate overlays, and that the seperate 
overlays got more feedback than did package.mask-ing (as with things such as 
Gentopia).

R Hill confirms this and states that package.mask seems to bring an unwanted 
"we won't support this unless you provide patches" sort of approach, while 
overlays are specifically made for the purpose and welcome any sort of 
reporting.

Kevin F. Quinn states a list of things that the x86 arch team should compose 
of (listed here [2] to keep this email shorter).

Ciaran McCreesh states that the ebuild quiz (point in [2]) is not difficult 
and should still be kept that way. 

Kevin F. Quinn states that the ebuild quiz is mainly oriented towards 
developers as the audience, and is not recommended for users that are simply 
told to "test a package and note the USE flag configuration, seeing what 
happens".

Nathan L. Adams states that users need to work with both an ebuild quiz and a 
qa testing quiz

Homer Parker states that an arch testing quiz is a good idea and mentions the 
amd64 one centralized for QA and troubleshooting.  He also notes that while 
some arch testers become devs, some are simply content with arch testing.

Tom Martin mentions that the maintainer arch is valid, and that the current 
policy is that no arch team should go past a maintainer in stable marking.  
He also states that some packages are taken up by non-x86 maintainers and 
don't have x86 keywording because of that.  He also mentions that the x86 
team should be small considering the number of packages that will be changed 
as a result.

Nathan L. Adams states a policy should be created whereas maintainers have a 
maint keyword, arch teams don't go past that, and they can optionally deal 
with their own maintainer arch.

Ciaran McCreesh and Stuart Herbert agree that the x86 team needs to be 
coordinated and a full arch team.

Daniel Goller mentions that if arch teams could not override some overly picky 
package maitnainers, their powers would be very limited.

Stuart Herbert also states that arch maintainers can be somewhat overly picky 
as well and that the problem comes from both sides.  He then goes to state 
that arch teams that override package maintainers should take on the burden 
of support.

Ciaran McCreesh states that ~arch keywording is just for that purpose, and 
that a maintainer shouldn't put something in ~arch if it's not stable 
capable.

Some more discussion follows asking that ~arch be used as the stable ready 
marker.  It also is stated that ~arch is not about testing for a package 
readiness, but more ebuild readiness.

[1] http://article.gmane.org/gmane.linux.gentoo.devel/31060
[2] http://article.gmane.org/gmane.linux.gentoo.devel/31100

Chris White

-- 
gentoo-dev@g.o mailing list