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@gentoo.org mailing list
