On Tue, 14 Jan 2014 18:22:51 -0500 Jeff Horelick wrote: > I think the simplest short-term solution might be to add teams that > are looking for ArchTesters to the Staffing Needs page on the wiki Adding a lot of them could make it noisy, I think we could just make one entry to link to a page that lists them in detail; alternatively we can work with some kind of categorization on the same page. You could determine the success of the current version by checking whether BSD and x86 arch teams (currently listed there) have seen enough new arch testers over the time the need was listed. > and promote that page like crazy. It's linked to from the Gentoo homepage near the bottom of the left hand side list; I was thinking, maybe we could add something like a 200x250 sized banner advertisement somewhere advertising the ability to contribute and forward people to a relevant Wikipedia page. Besides it being linked there, hwoarang has very recently linked to this from the Google+ website; on IRC we have this URL near the end of the #gentoo-dev-help topic. Recently I revamped https://wiki.gentoo.org/wiki/Contributing_to_Gentoo where there are two lines that could invite people to the arch testing business, these two: - Become an arch tester; for instance, check out the arch teams x86 and amd64. - Become a Gentoo Developer and join one or more of the many herds to contribute to interesting project(s). But I feel like that page itself can use much more attention. Is anyone here good in advertising and promotion skills? :) > I'd be more likely to do a lot more > stabilizations if it wasn't just me going on my experience and > running through the AT procedures myself (they're also a bit lengthy > if you follow them properly, which I prefer to). We could optimize the AT pages to make them look less scary to people; especially if it's described as 'bit length' it doesn't sound like a neat workflow that I would be wanting to read through, maybe some things would be too wordy here or some things could be put in a tool? (Haven't actually looked, but reading length can matter a lot) > I do feel some arches should be a bit deprecated. Not quite as > severely other arches the council deprecated a few months back, but > something. Yes, maybe; whatever we do, I hope it to be an arch-by-arch approach. > Also, to ease the burden on Arches, it'd be nice if the maintainer > would do some of the archtesting work on all their available arches > rather than making the AT's/arch teams do it...For example, almost > everyone who has a amd64 system, can easily make a x86 chroot (or VM) > to test in. The problem (at least for overworked maintainers) is that this moves efforts from one place to another; and thus, while this could result in near the same quality stabilizations, it will remove (or delay) either work efforts or quality in other places due to the lack of time. > Another option (and I don't mean to step on any toes or call anyone > out here, these are just examples) may be to just deprecate > stabilizing certain software. Packages such as the stuff in app-vim/ > or app-emacs/ or some games or some scientific software. For the > editor plugins, most people do not get them from the package manager > I feel and a Vim plugin requires almost as much arch testing work as > a new version of grep, for example... Sounds like a good idea, but how do we translate that to the user; always mark them stable, or always mark them unstable? Do we want users to explicitly accept keywords on these packages? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D