Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: jdhore@g.o
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Wed, 15 Jan 2014 00:29:13
Message-Id: 20140115012809.744114d1@TOMWIJ-GENTOO
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by Jeff Horelick
1 On Tue, 14 Jan 2014 18:22:51 -0500
2 Jeff Horelick <jdhore@g.o> wrote:
4 > I think the simplest short-term solution might be to add teams that
5 > are looking for ArchTesters to the Staffing Needs page on the wiki
7 Adding a lot of them could make it noisy, I think we could just make
8 one entry to link to a page that lists them in detail; alternatively we
9 can work with some kind of categorization on the same page.
11 You could determine the success of the current version by checking
12 whether BSD and x86 arch teams (currently listed there) have seen
13 enough new arch testers over the time the need was listed.
15 > and promote that page like crazy.
17 It's linked to from the Gentoo homepage near the bottom of the left
18 hand side list; I was thinking, maybe we could add something like a
19 200x250 sized banner advertisement somewhere advertising the ability to
20 contribute and forward people to a relevant Wikipedia page.
22 Besides it being linked there, hwoarang has very recently linked to
23 this from the Google+ website; on IRC we have this URL near the end of
24 the #gentoo-dev-help topic.
26 Recently I revamped
27 where there are two lines that could invite people to the arch testing
28 business, these two:
30 - Become an arch tester; for instance, check out the arch teams x86 and
31 amd64.
33 - Become a Gentoo Developer and join one or more of the many herds
34 to contribute to interesting project(s).
36 But I feel like that page itself can use much more attention.
38 Is anyone here good in advertising and promotion skills? :)
40 > I'd be more likely to do a lot more
41 > stabilizations if it wasn't just me going on my experience and
42 > running through the AT procedures myself (they're also a bit lengthy
43 > if you follow them properly, which I prefer to).
45 We could optimize the AT pages to make them look less scary to people;
46 especially if it's described as 'bit length' it doesn't sound like a
47 neat workflow that I would be wanting to read through, maybe some
48 things would be too wordy here or some things could be put in a tool?
50 (Haven't actually looked, but reading length can matter a lot)
52 > I do feel some arches should be a bit deprecated. Not quite as
53 > severely other arches the council deprecated a few months back, but
54 > something.
56 Yes, maybe; whatever we do, I hope it to be an arch-by-arch approach.
58 > Also, to ease the burden on Arches, it'd be nice if the maintainer
59 > would do some of the archtesting work on all their available arches
60 > rather than making the AT's/arch teams do it...For example, almost
61 > everyone who has a amd64 system, can easily make a x86 chroot (or VM)
62 > to test in.
64 The problem (at least for overworked maintainers) is that this moves
65 efforts from one place to another; and thus, while this could result in
66 near the same quality stabilizations, it will remove (or delay) either
67 work efforts or quality in other places due to the lack of time.
69 > Another option (and I don't mean to step on any toes or call anyone
70 > out here, these are just examples) may be to just deprecate
71 > stabilizing certain software. Packages such as the stuff in app-vim/
72 > or app-emacs/ or some games or some scientific software. For the
73 > editor plugins, most people do not get them from the package manager
74 > I feel and a Vim plugin requires almost as much arch testing work as
75 > a new version of grep, for example...
77 Sounds like a good idea, but how do we translate that to the user;
78 always mark them stable, or always mark them unstable? Do we want users
79 to explicitly accept keywords on these packages?
81 --
82 With kind regards,
84 Tom Wijsman (TomWij)
85 Gentoo Developer
87 E-mail address : TomWij@g.o
88 GPG Public Key : 6D34E57D
89 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D


File name MIME type
signature.asc application/pgp-signature


Subject Author
[gentoo-dev] Re: rfc: revisiting our stabilization policy Duncan <1i5t5.duncan@×××.net>