User:Klausmann

Developer
Name	Tobias Klausmann
Nickname	klausman (www.g.o link)
Email	klausman@gentoo.org
Packages	p.g.o/klausman@gentoo.org (commits)
Is active	Yes
Projects

Leader of the Alpha Arch team.

IRC nick: Blackb|rd.

GPG Key ID: 0xD4CFDD5901015BAE

Also maintaining sundry ebuilds of interest. Author of:

• app-admin/lib_users
• dev-python/pymetar
• net-analyzer/carl
• games-misc/fortune-mod-kernelcookies

Stabilization, Keywords etc.

Beyond the base policy of Gentoo Linux when it comes to testing and stable keywords, I have my own rules that are a bit more nuanced and sometimes specific to the architecture I work on (alpha).

What gets a keyword

Stable keywords

Since Alphas are not particularly fast compared to more modern processors, we can't guarantee the same testing and keywording latency that for example amd64 has. That there are fewer testers for alpha exacerbates this problem. The following things make it less likely that a package gets a stable keyword for Alpha:

• Long compile and/or test time, especially if releases are frequent
• Complex testing procedure
• Upstream doesn't care about alternative architectures
• The program itself uses a lot of resources
• Special hardware requirements
• Niche software

Note that ultimately it's the arch team's decision whether to support stable keywords for packages. There is no appeals process except the maintainer convincing us that it is useful to have. That said, there are also aspects that make me more likely to support keywording a package:

1. Good test suite that runs in parallel
2. Package is a good alternative to a more heavyweight one
3. Upstream is aware of other architectures and supports them
4. Package broadly in the accessibility category, e.g. braille reader software and the like

Testing keywords

In principle, the same rules as for stable apply, except slightly less so. If there is an agreement with the maintainer that the package will never go stable, this is even more likely.

There are packages we can't ever keyword, typically because Alpha-the-arch is not supported by upstream. These typically are threading libraries like dev-python/greenlets, platform-specific packages (like grub or lilo) and binary-only packages like the nvidia proprietary drivers. This typically also means that reverse dependencies are impossible to get keyworded, unless they have USE flags that can be used to make the dependency optional (while the dependent package is still useful).

Stable and keyword requests

We use the same stable/keyword process as all the other arches. That is:

1. Maintainer files bug with all necessary atoms and CC's alpha@
2. One of us tests the package, at a minimum the compile, test and install phases
3. The keyword is added and repoman is happy with the resulting depgraph.
4. Changes are committed
5. Bug is updated with a comment along the lines of "Stable/Keyworded on alpha." and the alpha@ CC is removed
6. If alpha@ is the last arch CC'd, resolve the bug as fixed.

There are a couple of situations when the above list is not just completed:

• The list of atoms is not a valid dep graph (usually missing deps)
• The package fails its test suite and this is not a security bug
• Repoman has other fatal complaints about the package
• The arch team decides that this package will not get keyworded at this time

Of these, the first one is the most common, followed by the second. In the second case, the AT will typically file a separate bug with the build log and Portage info and assign it to the package maintainer. The, the new bug is added as a blocker to the original stable/keywording request.

Security bugs

On the whole, the strictness of the requirements above is a bit loosened for security bugs. Whether breaking alrge parts of the package's functionality is worth not having a vulnerability is decided on a case-by-case basis. This obviously is only relevant for arch-specific failures. If the new version is broken somehow for all arches, Alpha will follow the consensus decision of the security team, the package maintainer and the other arches.

Priorities

As time is limited, I will tend to keywording requests in the following order:

1. Security bugs
2. Stabilizations with no blockers
3. Stabilizations with blockers (since these are sometimes arch-specific)
4. Re-Keyword requests (typically due to new deps that need keywording)
5. Keyword requests with no blockers
6. Everything else

Within those categories I generally go by bug number, since that is the easiest way to make things vaguely chronological. I may skip bugs that look like lots of work if my time is limited — I'd rather do three five-minute bugs than do nothing because there is an older bug that would take twenty minutes.

If things are urgent but not obviously so, it's perfectly fine to ask on IRC if I can do a quick test+keywording. Note that I will quickly stop being available for that if this is abused.

Hardware access

Some bugs are best tended to by the maintainer. For that, it may be necessary to have access to Alpha hardware. We have a somewhat beefy (relatively speaking) development box that I will grant access to, preferably to Gentoo devs. Upstream can get access if the package is important and useful (e.g. some gcc maintainers have access).

If you need access to debug something, poke me on IRC.