KDE/KDE Team Cheat Sheet

From openSUSE

How To Be A Member Of The openSUSE KDE Team

In no particular order here is a list of things we do and resources on how we do them:

Security

Security bugs are a high priority for the employees. Use Bugzilla and SWAMP (internal only).

L3 Bugs

L3 bugs are the ones that customers pay for and must have a quick reaction. Employees use Bugzilla and watch out for the "L3" prefix. Community members get to do fun stuff instead.

Version Updates

KDE Releases

openSUSE has a good reputation for providing KDE releases promptly. Major and minor releases are usually handled by a single team member for efficiency.

Application releases

Applications outside KDE modules may release at any time. Keep an eye on Package Warrior notifications of new versions, by email. New packages should be created for hot new applications, monitor the KDE package wish list.

Testing migration between major versions

kde4-migrate is the tool for copying KDE 3 configs to KDE 4. Config migration requires testing since apps may not properly support importing their KDE 3 incarnation's configuration (kmail).

Features

Features may be listed in FATE (internal) and openFATE. Also keep an eye on the openSUSE Idea Pool.

Translations

Mostly we try to take upstream translations. Features we develop that do not fit within the upstream release cycle may require openSUSE translations. For this to happen we need 1) to make the new work translatable 2) to copy the .pot files into the translation repository on time and 3) to return the copied translations to the appropriate -lang package.

Bugs

Bugzilla is your major tool here. Individual team members' reports are easily accessible at hall. Pay attention to bugs.kde.org for applications you specialise in for upstream fixes, and significant bug reports that aren't reported at bnc.

Triage

Incoming bugs to kde-maintainers@suse.de should be triaged. We currently distribute this work by rotating responsibility for triaging bugs on a weekly basis around the team members.

Follow-up

We endeavour to respond promptly when users provide information we've requested on a bug report. You can use advanced bugzilla queries to look for bugs that have been hanging around for a long time.

Fixing

This takes most of our time.

Packaging

Packaging is what being a distro is all about.

Package Database

All packages that are distributed as part of openSUSE releases must be correctly registered in the (still internal) Package Database.

Package Pattern updates

Patterns are the sets of packages that control what is installed by default and what various 'Development' selections include.

Build Failures

Packages fail to build for a variety of reasons - changed dependencies, changes in their dependencies, flaky build hosts and toolchains, and build problems peculiar to exotic architectures. Read the build failure notification emails sent to you personally and to the team. Monitor the openSUSE Build Service for failures in projects we maintain.

Online updates

Security and critical fixes should be shipped for released distributions. Use [Fix_Is_Ready:<distro>,...] in the bug subject to indicate that a fix is pending. Use SWAMP (internal) to track the workflow of a bug being fixed via an online update.

Integration changes

Big changes in the distribution platform require adaptation in our packages. These can include things like PackageKit, NetworkManager, ConsoleKit, X, multimedia subsystems. Keep your ear to the ground on opensuse-factory@opensuse.org, research, listen to project managers, and browse FATE so you are not surprised.

Licensing and Crypto

As a software distributor, we have to make sure that we follow the licenses and crypto export requirements of the software we distribute and that we declare these licenses correctly in our packages. Expect nastymail if you don't.

Other distros' packaging

Other distros' packages can save a lot of time when backporting features or bug fixes. Right, Kubuntu? ;)

Community Building

Put the 'open' in openSUSE. Befriend a user today, tomorrow she might help triage some bugs, package something in the openSUSE Build Service, or tell you something that will help you find the cause of a bug.

Testing Builds

Both for ourselves and for the rest of the distribution's developers, we try out the latest builds and report the things that don't work.

User Support

As experienced KDE users we are able to spot the causes of problems pretty easily. Share your expertise at #opensuse-kde.

Developer Support

There are a lot of KDE users in the various openSUSE offices, and they sometimes have problems. We can't kill 'em, so we might as well help 'em.

Putting it all together

Our goal with this page is to make it possible to fulfil the regular tasks as efficiently as possible, leaving as much time for doing amazing new stuff. We have defined the following desirable qualities to do this.

Awareness

It helps if we're all aware of what we're working on despite being in different locations. We are suggesting to send around a weekly mail summarising our activities under the above headings

Fairness

So that all team members get a crack at the fun stuff

Responsiveness

This is only fair to our users who take the time to report things and customers who've paid for it.

Optimisation

Tricks and scripts that you've developed to make things happen quickly deserve to be shared.