Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

On Tue, 14 Jan 2014 18:22:51 -0500
Jeff Horelick <jdhore@g.o> 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@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D