openSUSE:KDE Maintainers Cheat Sheet

Jump to: navigation, search

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. If you are doing updates of entire KDE releases (4.5, 4.6 etc) make sure upstream KDE knows about you, you are subscribed to kde-packager@kde.org and you have early access to release tarballs for packaging. File a sysadmin bug at http://bugs.kde.org to obtain this access. You will need to give references before you receive access.

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.

This did not happen for openSUSE 12.2. So there are untranslated strings for openSUSE specific patches (e.g. the sysinfo entry in kickoff). An Howto for this is found at https://gitorious.org/opensuse/kdebase4-opensuse/blobs/master/totranslate/. (ctrippe)

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. You can watch any bugzilla account in Novell bugzilla by adding it to the list in Preferences->Email Preferences, near the bottom of the page. For watching changes in shared bugreports, including all new KDE bugreports, add 'kde-maintainers@suse.de'. For more information see openSUSE:Bug_Screening_KDE

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.

Bug Squashing

We try to do regular Bug Squashing Sessions to keep the number of bugs manageable. This is always a good opportunity to get new people involved. For more information see openSUSE:Bug_Squashing_KDE

Packaging

Packaging is what being a distro is all about.

ToDos for a new openSUSE-version

(This should probably go on a separte page in the wiki and is only a starting point)

Special features of some KDE packages

There are a few KDE packages, most notably kde4-l10n, where the source files contain a script called pre_checkin.sh. This script must be run before committing changes to the OBS. In the case of kde4-l10n the kde4-l10n.spec file is automatically generated in this way from the kde4-l10n.spec.in file.

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 work

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.

Package requirements

Packages often require their build or runtime requirements amending, as the upstream software evolves. Look for build system output warnings that optional dependencies were not found, and add them to the BuildRequires: packages. New runtime requirements are usually expressed as Requires: lines in the specfile for the sub-package containing the code that has the requirement. Eg libbluedevil1 Requires: bluez.

Configuring software

The default configuration for software from upstream may require modifications to meet our needs. For example, by default it may load a plugin that is known to be buggy. We do this by including default configuration in the openSUSE branding package kdebase4-workspace-branding-openSUSE, derived from kdebase4-openSUSE. Note that upstream default configs are in /usr/share/kde4/config/, distribution-added default configs (most of our changes) are in /etc/kde4/share/config and Live media specific configs are in /usr/share/kde4/config/SuSE/default/<filename>.live and are copied into the Live user's .kde4 on login by scripts like /usr/share/opensuse-kiwi/live_user_scripts/kde4.sh.

Updating Visual Identity

Visual Identity refers to the customised look and feel of the distribution, and also to configuration changes.

  • kdebase4-openSUSE contains our visual identity
  • http://gitorious.org/opensuse/kdebase4-opensuse is the repository
  • Do not make changes only to the kdebase4-openSUSE-<version.tar.bz2 in the package, commit them to the git repository then run "sh update_rpm" there to generate the tarball. Otherwise your changes to the tarball will be removed by the next run of the script.
  • Remember to update metadata (descriptions, preview images) as well as screenshots. Incomplete list:
    • kdm theming: branding/root/usr/share/kde4/apps/kdm/themes/SUSE/
    • kde login splash: ksplash/ksplashx-suse/
    • default wallpaper: branding/root/usr/share/wallpapers/openSUSEdefault/
    • kwin decoration: branding/root/usr/share/kde4/apps/kwin
    • plasma theme: branding/root/usr/share/kde4/apps/desktoptheme (as this includes some modifications of upstream default plasma theme files, check for bugfixes to these and apply them to our version)

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? ;)

Pre-release versioning

It is sometimes necessary to change the package version from that provided by upstream. Usually this is because a pre-release tarball is made available named something like kfoobar-4.8.0beta1.tar.bz2. It is a mistake to package this as "kfoobar-4.8.0beta1.rpm" because RPM sees "4.8.0beta1" as newer than "4.8.0", making it impossible to automatically update to the release. We conventionally assign such packages a lower version number as follows:

  • x.(y-1).6n - pre-alpha snapshots where n starts at 0 and increases monotonically
  • x.(y-1).7n - alpha releases
  • x.(y-1).8n - beta releases
  • x.(y-1).9n - release candidates

The correct Version for kfoobar above would be 4.7.80. In the specfile, define %rversion for the "real version" given by the tarball: 

%define rversion 4.8.0beta1
Name:           kfoobar
Version:        4.7.80
Source0:        %{name}-%{rversion}.tar.bz2

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.

Retrieved from "https://en.opensuse.org/index.php?title=openSUSE:KDE_Maintainers_Cheat_Sheet&oldid=137208"