Home Home
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Author Archive

Buildservice and L3

July 10th, 2008 by

These days some people from various teams spent a lot of time the last days discussing topics around L3. L3 means Level-3 support and is one of the services that we offer for our enterprise product series. It is about bugs which are not solvable through our support organisation but require developer eyes to stroll through source code.

What that has to do with openSUSE you might wonder. Well, since we’re currently working on switching our internal build process to a Buildservice based solution, L3 comes into play as well as other parts that are hardly visible for the community but important for the business.

L3 is a really tough game: Customers are paying money for the service and if they call they expect premium service quickly. Often enough enterprise operations are endangered by L3 bugs (or it is said that it is 😉 and clearification is needed quickly to relax the situation.

For the brave guys offering this service that means that they need to replay the customer situation quickly, debug, find the bug and if needed provide a fix for the customer.

The customer of course can tell more or less accurate which system he is running on which hardware. But than it’s getting rough for us: Finding the correct source for this constellation might sound easy, but if one adds up the amount of products that we maintain, it’s subflavours and service packs and also considers the lots of maintenance updates that the customer is expected to install, it becomes clearer that there are lots of possibilities and huge hard drives with content ;-).
Having found the correct source debugging (often together with the customer under time preasure), fixing and providing a fixed package begins.

L3 is an impressive bussiness for me, done by courageous guys.

Even more nice that the Buildservice helps a lot here because it makes at least building of debug info packages and fixes easy. A well thought through project structure in the Buildservice linked together with sourcelinks and aggregrations (which is a science for itself which one where 😉 eases (at least) the source organisation a lot. Other things also sound promising.

There is still some work to do until all peaces fit together but we are looking forward to helping the L3 collegues to improve their processes with the Buildservice and maybe some other tools.
I know, this is not exactly related to community questions but I thought it might be interesting to read about these things from time to time as well…

Hermes grows up

June 20th, 2008 by

As promised in my other blog about Hermes it grew up a bit since then. I was able to install it finally on the Buildservice production machines. Darix and Adrian helped me to get things underway. As the first process of the backend, the srcserver is notifying Hermes about things that happen: Commits to packages, udpates of packages etc.

Since starship is not yet in the shape that we really want to use it, we’re only offering RSS feeds so far, not yet personalized. Under the URL http://build.opensuse.org/feeds/allevents.rdf you find a RSS feed with all notifications the srcserver comes up with so far.

We realise that this feature is especially interesting for collaboration in general and especially for the new request stuff coming with the upcoming release 1.0. As a consequence we have created a feed that only contains the notifications about requests: Creation, change and deletion are reported to http://build.opensuse.org/feeds/requests.rdf

This is the first step with Hermes in production. Note that it is still beta and nothing one could expect proper functioning from. I am leaving to a two week vacation today and this is what I could still come up with before. Hope you enjoy it a bit – please give feedback, especially which notifications you would like to see coming through.

These are the areas where I would continue to work on after vacation if you don’t come up with other prios:

  • Starship – Message displaying, configuration of notification subscriptions.
  • Personalization – only show me notifications about projects where I am involved.
  • More output agents – mail, jabber, personal RSS
  • More usefull notifications, with help from the backend people

If you want to know more about Hermes find it in the infrastructure svn module (don’t miss the docu in the doc directory)

Little Hermes

June 16th, 2008 by

some code was added to the buildservice backend already that generates Hermes notifications. That means that Hermes is getting closer, I will work this week to start a first test with Hermes on the production build service.

So let me introduce Hermes a bit.

Hermes is a system that helps it’s user to get back the decision about who is sending a message when and in which way. Using Hermes it is up to the user to decide if a message comes through at all, when and in which way. Hermes is going to be the central part of notifications in the openSUSE Buildservice.

Digest messages will be supported through Hermes. That means that messages (mostly automatically generated) of the same type coming regularly can be combined to one message combining all the bits. For example, imagine a notification about a package build fail. It might not make sense to send lets say 50 of them a day due to numerous rebuilds on different platforms that failed. It seems to be much more efficient to combine all these 50 to a digest message that lists all of the 50 fails. However, it’s users choice in Hermes.

The other important feature of Hermes is choice in the way of delivery. It is up to the user in which way the message comes through: Mail, RSS and jabber notification are already implemented in beta stadium, others may follow. It’s users choice based on the message type when and in which way the message is delivered.

Hermes LogoThe backend already has some code in it to notify Hermes. I hope I will be able to make let’s say some RSS feeds or mail running this week, especially for the submit requests. That would be another step into collaboration with the buildservice.

And since I seem to talk a lot about Hermes these days, Robert was cool enough to come up with a very cool logo for the (still little) Hermes. Do you like it? I think it is awesome – kind of 1960’s aircraft company 😉

Thank you very much, Robert!

More about Hermes to follow…

Collaboratio

May 21st, 2008 by

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.

How do you like this story?

Wiki on a Stick

May 14th, 2008 by

Have you ever had the problem that you start writing something in a wiki, take some time to think, drink coffee and do other things and finally press Save in your browser and realise that your session with the wiki has already ended?

There is a very cool thing that helps here, I saw it on Christian Hüllers screen recently: woas or Wiki on a Stick. This is a single (not simple 😉 html file that you open in your browser and it comes up as client side wiki that allows to edit documentation offline in wiki syntax with a browser based editor etc.

The nice thing is that the result is still one file. It is not really nice because of tons of styles and javascript functions in it, but it is just one non binary. That allows to check it into a source controll system and the problem “Maintaining the docs in Wiki or at the source” is a bit easier to decide now. Nice.