Posts Tagged ‘Collaboration’

In my last blog I was mentioning the “Distribution Wettstreit” which translates in “distribution competition” held on the Chemnitzer Linuxtage event. The idea of that session is to have distros lined up on stage and give them a task and see how each of them is able to solve it and compare that. I participated for openSUSE but the session left some question marks for me. Here are my thoughts how the idea could be improved.

As far as I know it happened the second time in Chemnitz, were Debian, Fedora, Mandriva, Pardus, Ubuntu and openSUSE were on stage. The tasks we got were every day problems, such as playing a flash movie or how to display a html 5 page. openSUSE was lucky with a one week old release, so wonder why we can handle HTML5 directly and others who released earlier can not?

Apples and Oranges

I have to say that I do not like this kind of session too much. It is great to compare distributions, and also to do it kind of interactively and live. But even given that all involved know that its not about finding a winner and a looser, in this format there are too many parameters that influence the whole thing: First, the release date. Younger distros tend to be better than older ones. Second, it highly depends on the person who sits in front of the machine and explains what he does to solve the problem. One must be able to solve the task technically, and than she/he must be able to talk about it appealingly.

Different distros target at different user groups, and you quickly compare apples with oranges. I think it should be realized as a benefit that we’re different, and that does not necessarily need to end up in a competition everywhere. Moreover, we should appreciate if people remain playful and try distros as they like instead of trying to nail them to one forever.

Maybe next time we can rather have a “The combined power of the Linux variety” -session [working title] instead? In that we could try to work out the differences between the distros and which user groups could benefit from them. I mean, the variety in the FOSS community is the great advantage that we have over other systems and we should express it. And our similarities which we certainly have should also be brought on the table. To whom do we really compete? I guess we should be compared against commercial systems which tend to lock the user in with huge consequences or have security-, innovation- and other issues. Why not line up on stage and show the audience how we together beat these system with free software in various ways for the good of the user?

Yes, playing flash movies is a every users problem, and I know the “I don’t care, it simply needs to work!”-attitude lots of users do have. We as free software distributions had and have to find ways to deal with it, and we all have our solutions. But whats really important is not to present new users that we even though in general can not work with Flash, we found a workaround.

The more important message is why its dark in some corners of FOSS world, how that can be improved and who is able to change that. I think it would be awesome if that could be taken more into account the next time we have the opportunity to speak to such an audience as distributions together.

Sometimes a packager asked himself, who has already packaged this Software? Maybe the Packagingfiles can help me to fix a error? Or maybe an other packager has a written a patch that i can use for my situation?
Philipp L. Wesche knows this situation, and he wrote a program, that allows to view in other Distributions and Repositories, who has a specific Software packaged. The commandline tool “whohas” supports Arch, Debian, Fedora, Gentoo, Mandriva, openSUSE, Slackware, linuxpackages.net, Source Mage, Ubuntu, FreeBSD, NetBSD, OpenBSD, Fink, MacPorts and Cygwin. Philipp wrote this tool in Perl and was designed to help package maintainers find ebuilds, pkgbuilds and similar package definitions to learn from.

The openSUSE team in Nürnberg invites everybody interested in Linux and in particular in openSUSE to join our Christmas party on Wednesday December 16 in the basement of our office building in Nürnberg. We’ll give some presentation about openSUSE 11.2 in action, GIMP and how to participate at our project. Beside of the presentations we have some machines where especially openSUSE Education and the openSUSE Build Service will be shown but openSUSE 11.2 is available too, of course. More information
We hope to reach out to many local people in the Nürnberg area.

This week kolab became one small step closer to realize feature request 307846: include Kolab in openSUSE. Although it will take lots and lots of more work to achieve this goal at all. The one step closer was realized in cooperation with the openSUSE cyrus-imapd maintainer R. The openSUSE cyrus-imapd spec file in the repository server:mail spec file has been extended with information about kolab, but the actual execution of the information has been switched off. With the Build Service link functionality the package server:mail/cyrus-imapd has been linked to the package server:kolab:UNSTABLE/cyrus-imapd-kolab, where the kolab functionality gets built. This is achieved by activating the variable with_kolab in the project related configuration file:# osc meta prjconf server:Kolab:UNSTABLE
%define with_kolab 1
Macros:
%with_kolab 1

See the Build_Service prjconf page in the openSUSE wiki for more information about this awesome functionality. This way the cyrus-imapd-kolab package inherits everything from the openSUSE base cyrus-imapd package.

One drawback for kolab administrators, you have to manually correct the currently installed kolab packages. Start with downgrading cyrus-imapd-kolab (it only downgrades the Build service version and not cyrus-imapd itself):# zyp in cyrus-imapd-kolab
This will install the dependent package perl-Cyrus-IMAP-kolab instead of perl-Cyrus-IMAP and perl-Cyrus-SIEVE-managesieve-kolab instead of perl-Cyrus-SIEVE-managesieve and it might remove kolab and perl-kolab.

Now reinstall kolab with:# zyp in kolab
that should be sufficient to be in sync with the repository again. Don’t forget to restart the services, with:# rckolab restart

This week also showed the power of the build service, as I could install kolab within only some minutes after installing openSUSE-11.2 in Virtualbox, while I never installed openSUSE-11.2 before.

The kolab installation in openSUS-11.2 made some problems visible in kolabconf -n. The latter has been fixed, it was a general problem in kolabconf and did not have anything to do with openSUSE-11.2.

The kolabconf problem however required some debugging, with a resulted spin off that the spamassassin daemon spamd is no longer activated via the startup scripts, but as a library of amavisd instead. That is the way amavisd and spamd have been configured in kolab, but what was not honored in the kolab setup on openSUSE.

Due to the change in the amavisd and spamd deamons, the script kolabsrv has been extended, and can now show a list with services required by kolab and what their current status is (see screenshot):

kolabsrv list and status output

The main task of kolabsrv is to convert the openpkg service names to the distribution dependent names.

The kolab project is heading towards a new release 2.2.3 with a planned release date in December 2009.

In one of the replies of Sasha’s brain dump, a references was made to project-builder, a project similar to the openSUSE build service. Although the OBS and project-builder may be similar, some people are wondering what the differences (1) and (2) are.

PS: many thanks that M. from Novell, who made my Lizards blog account working again. For the most part of this week, I’ve not been able to login to my blog account. After logging in with the correct credentials, I was referred back to the Lizards entry page. M. knows the details, so if this happens to you contact M. from Novell 🙂

This morning when I started to work I found a bug report about Hermes. Nothing amazing so far, but hey – there is a patch attached to fix the problem!
We all know that this is the way it works in communities, but still, everytime it is a very good experience to get a patch that fixes something that was overseen, not thought through or forgotten for whatever reason. It means basically that somebody has found the problem and has not gone away but found it worth to take a closer look and help to fix it. For me, that is a great acceptance of my work and I bet that most developers feel that way.
So, if you want to motivate a developer, simply send a patch 🙂
Thanks, Christian, for bnc #537106 coming with a fix, you made my day.

Collaboration is not always an easy thing: Talking, meetings, making decisions and finding compromises. Sometimes I have the impression that some people in our business find this inter personal activities very exhausting and thus prefer to work on their own. Depending on how genius one is that works far. But for obvious reasons working alone has limits. If we talk about a whole Linux distribution for example one can not succeed: The working power, creativity and time of one is not enough.

That is one reason why we consider it as one of the keys for success that the Build Service enables people to work together in a useful and non annoying way. We think of tools in the Build Service which help. That is difficult because some formalism and guidance (in business often called ‘process’) is needed to keep things going in a transparent and reproduceable way. Control should stay there where it needs to be, for example at the maintainer of a project. On the other hand collaboration tools should not constrict people and their working together.

Here is a little story of Karl who wants to change something in the openSUSE Factory project. He needs to work with the Factory maintainers and this is how that is planned for the future:

Karl, a developer working for a small software company, loves openSUSE but not really the one package Kabax because there is a packaging problem Karl has analyzed.

Karl wants to change that to make sure that the next version of openSUSE contains a good version of Kabax.

For that, a branch of Kabax in Factory is needed where the fixes can be put in, built and tested. Karl uses osc to create a branch. The package is not really maintained in Factory itself, because the few Factory maintainers can not care about all packages there. Kabax has a Devel Project entry in its meta data that points to the project where it is actually maintained by the expert Karsten.

Because of the devel project, osc branches not really from the Factory package but from the development project where the development happens by Karsten. That might be different from the Factory package, but is clearly the development version that soon will be synced to Factory. When that happens is up to Karsten and the maintainers of Factory.

In the branch Karl starts to work on Kabax and creates a beautiful patch. Since his branch package also lives on the Build Service, it builds live for all relevant repos and along the changes of the devel project.

Once Karl is happy with his work he raises the attention of Karsten on his change by creating a submit request. A request in general informs others of something somebody else has done which requires action. In the case of the submit request it tells Karsten that there is a valuable change to his package that should make it’s way to Factory. Karsten now accepts the request and Karls contribution is in.

The nice thing about all this is also that the branch packages as well as the requests are open and visible to everybody who is interested in. That gives us the transparency we need. And of course that does not only work for Factory but for all projects if one wants to change something on a package where he/she does not have permissions yet.