The boosters team promised to talk about what happens in our sprints – the two week time boxes in which we work on our projects. The last sprint ended on october 27th and we still owe you what happened.

Please understand this little report as usual as an invitation to ask, comment, suggest things and of course fire up your editor and contribute if you like.
You find us on IRC in channel #opensuse-boosters or on the opensuse-boosters mailinglist.

Discoverable centralised documentation driven by Lubos, Egbert, Henne, Petr and Federico.
This squad is working to provide a better discoverable developer documentation around openSUSE.

In the last sprint a lot of discovering “how things are usally done with wediawiki” has happened, such as how wiki content
is sorted or how portals are used. That went in parallel to the discussion Rupert started on the wiki mailinglist, good enough that both efforts go combined now – everybody is asked to join the discussion on the wiki list.

We also discovered that the media wiki update has not yet gone through, the problem was that our iChain plugin was broken with the new version of the Wiki. The squad will fix that.

Integrate all infrastructure under one Umbrella driven by Klaas, Robert, Darix, Michal, Pavol.

We were still very much individually sitting around and fiddle with the Ruby on Rails framework to get on speed with it. For example the way how to integrate several Rails projects under one umbrella project was investigated.

The plan for the next sprint is to come to a first draft on how the new web structure should look like. We’re very much bound to our artists work, so if you are a screen designer, please get in touch with Robert to support him to direct the poor developer souls.

factory.opensuse.org – website visualising Factory status driven by Tom, Vincent, Will, Coolo

this squad was a bit understrength because of vacation and the upcomming 11.2.

Nevertheless they discovered a lot of dependencies in the OBS which are needed to set up the factory.o.o page. Some not so nice corners in the OBS were cleaned a bit which came to light when tom and Will were working to set up a test instance of the OBS.

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.

I did some interesting changes to the Hermes instance of openSUSE.

There have been complaints that it is not possible to follow requests that have been originated by oneself, which can result in the weird situation that one does not get information what happened to a request. I fixed that by adding a new subscription called OBS Request Author to the Hermes start page that informs you about all changes to a request originated by you. All people who already had a subscription on the request change notifications have been automatically subscribed. The subscription can of course be removed on the Hermes page if it is not wanted.

Another problem was that people who are subscribed on Build Failure with the _mypackages special filter were flooded by mails. That happens because the _mypackages filter thinks a package belongs to you if you’re either maintainer of the project or package. Since this is not what maintainers of big projects want I created a _mypackagesstrict filter that only fires if one is really the maintainer of the package. To enable this fix, please go to the Hermes Expert page to edit your subscription to BIULD_FAILURE. Edit the filter to set it to special value _mypackagesstrict.

I hope that makes Hermes again a bit more useful for you. Please let me know what you think!

Frank Karlitschek is joining us here in Nürnberg to work with us through the Hackweek. First project is to build and integrate an interface where webapps like www.kde-apps.org can get information from about binary packages that exist on the openSUSE Buildservice. That will make it very easy for upstream developers who build their package for several distros in OBS to get a list of available binaries in the application directory application. In kde-apps.org which will use this first you just need to enter the name of OBS project and package and the download links for rpms or deps will appear automagically. That takes away the pain to maintain lenghty lists of links to rmps

The specification is in the Wiki – Buildservice Concepts. Comments are welcome.

Nat blogged about Life Logging which means that one logs some life influencing parameters such as get up and go to bed times, blood pressure and more. While it might be funny to see some statistical data about ones life and maybe useful for pub evenings (”I bet you can’t beat me in that: On mornings after evenings where I had fife beers and the average temperature in the pub was not above 25°C and the amount of female guests was under 56% I make it to a shoesize of 46!”) I think that is quite useless. The human being is a too complex thing. It is influenced by tons of parameters. Measureing just can log a few of them. That would not be a problem, as long as one does that for the pub purpose, but as Nat says this is done for “performance optimization” of the person, it gets difficult.

I would love to argue now with more or less esoteric theories of what a person is influenced from like the polarization of the sunlight or earth rays but I fear that would not be appreciated by the usual audience here. So lets stress automatic control engineering (german Regelungstechnik, I hope that translates) which fascinated me earlier.

There is a base axiom that says: The more complex the system to control is, the more complex the model of the system is and the more parameters you have to take into account for your controller model to control the system to get the expected outcome. If your model of the controlled system does not align with the real system and/or wrong input parameters are picked you do not get what you want. The whole circle of controlled system and controller becomes unstable.

Given the complexity of the human being I think it is impossible to get something usefull out of measuring a few parameters of life and hope to get any hints for “performance improvements”. Its dangerous because it easily might become unstable.

And imagine how long it takes to log all the data and how complicated it might become – for example if you need to log the percentage of women in the pub every 10 minutes, that might lead to interesting social interaction. That time and trouble can be saved.

My suggestion is to improve self performance through self awareness. People need to learn to listen to themselves and do what is good for them. How that can be done? Well, yes, that seems not always to be an easy task. Suggestions around that I better leave that for the next “Dragos hints for a better personal life” lesson

You might have heard about Kraft, a KDE application aimed to people who operate small enterprises and have to write an offer or invoice sometimes. Kraft version 0.32 was released recently, the last KDE 3 based version, the KDE4 port has finally started.

Kraft is one of the candidates for the KDE group for financial apps which is a consolidating idea and was encouraged in Alvaros article A group to bind them all recently.

Unfortunately it is still a bit tricky to set up. To make it easier to check it out Live Images were created featureing Kraft on an openSUSE distribution with all tools and  interesting demo data. That is perfect to try it out and give it to friends and colleagues and talk about.

Please check the download page of the Kraft Homepage for details.

Last week Cornelius and me spent two days in the office in Prague to practice two days Ruby on Rails with our czech colleagues.
It was not only fun as usual but we had chosen Hermes as a trainings project. Hermes, our openSUSE notification system where the user decides how she wants to be notified definetely can make use of work so it were great to discuss with ten developers about it, hear their opinions and get some patches finished which will improve the system.

All went to a branch in svn and I hope to find time soon to merge it back and put it into production.
Thanks to our colleagues for hosting us and work with us. Maybe YOU also want to train on something real? Hermes is your friend – send me a note and get a free svn account

Kraft 0.32 was released a few days ago. Kraft is KDE software for people who operate a small business and want to generate documents like invoices or offers for their customers. Kraft helps to do that in a very efficient way with template texts and a calculation module and of course integration in KDE. Very important is an excellent print out (that’s the face to the customer) which Kraft does via an PDF export of the document.

I say ’small business’ as a target group and I mean small shops doing crafts like carpenters or plumbers or landscaping working alone or with a few people. I think free software and especially KDE is very good for these kind of companies. Larger companies usually go for specialised software, which is available for nearly all kind of crafts in all levels of usefulness and quality.

When I talk in the community about Kraft (I am of course not as good as Tackat in his best Marble-times) I sometimes feel that the coolness factor of this kind of software is not so big. People seem to think “How can one do this kind of boring, already-there software?”. Well, yes. This kind of software exists. But as free software and on KDE, well integrated into the desktop? Not that I am aware of.

Here are some good reasons to work on Kraft for me personally:

1. I think it is important that this kind of software is available. Not only Kraft, but other stuff people need for their business, for example financial software like KMyMoney. Well integrated in KDE this can enable another huge group of users which now uses other systems.
2. It is serious. Kraft is software people use to get their money. If somebody has done work and wants to invoice it she loves a well working software that saves time for her. But if it does not work, it becomes a serious issue quickly because only written and sent out invoices are good invoices from that POV.
3. Especially because there is much competition from the commercial side, it is fun to try to create free software that is even better from for example the usability perspective. It is real challenging.
4. I am somehow addicted This year I work for twenty years on this kind f software. If you like you can check out an underground video which shows software running on an Atari ST, used for daily business in my brothers landscaping company. I released that version in 1991, I still have an earlier release from 1990 which I could not get to run anymore. I started to develop it in 1989.

But back to the new Kraft-release: Beside other things I did some change to the tax system which make Kraft now useable internationally (shame  on me that the earlier versions where tied to german taxing too much).

So please, tomorrow first thing knock at the door of your handcrafter neighbor and ask him if he has thought about invoicing with Linux – Kraft  is with you, when you support him. Chances to get very interesting insights on how non-geeks see the computer world.

openFATE is now up and running for a few days. openFATE is, in case you missed the announcement, the community accessible feature- and requirements tracking for the openSUSE distribution. We developed and used the FATE system (which has some more components than just openFATE) before internally, but since we want to really open up development it was a logical decision to find a good way to let the community participate.

openFATE is not a stand alone system. The openSUSE distribution is as you know the base for our enterprise products. That means that discussions we do around openSUSE features sometimes have impact on what happens in the enterprise products later on, or vice versa. If features become important for SLE that also might have importance for openSUSE.

That is implemented in openFATE. It is connected to a common database which holds all information about features for all products. A chain of tools filters out information that can not go public.

It is basically about the SUSE Linux product family, where the openSUSE distribution and the SLE products are part of. If a community member gives input on a feature which has a product context for the SLE product, the input
is seen by the SLE product- and project manager as well as the involved developers. I think it is important to realise that this is part of our understanding of open development. openSUSE is not cut off the things we’re doing for SLE, but can have a direct influence.

So far we nearly had 300 changes to existing features and a whole bunch of new feature requests from the community. That is a very good result for the first few days I think. Please keep on giving your input. We are happy to see people involved in product planing, eg. for openSUSE 11.2 .

motivated by Aaron’s blog post More downstream fun I was thinking about how Fate could be a more important part of infrastructure in the Linux landscape. Fate is now an important part of the Novell/SUSE infrastructure and we are currently in the process to open it up for the openSUSE community. But could Fate also be useful for upstream integration? To let you participate in the discussion I think I should start with some explanations what Fate is and in which environment we are with it.

Fate is a system developed at SUSE over the last few years to track features and requirements for Novell Linux products.  The term “feature” is already is a topic for scientific papers, but how we understand a feature is a functionality  that is not yet in the product but required or wanted. It references future products, in most cases more than one such as SLE and openSUSE.

The little sketch illustrates the dilemma in which we are when it comes to product planning. Basically it is all about one  thing: decision taking. Decisions have to be taken about the new functionality  that goes into a product and the tasks internal people work on. This is based on the decision how the product should look alike from a high level point of view. To make a solid decision about the high level product it needs to be clear what we are actually able to put into the product at a given time. That is only a part of what is really going on but let’s leave it with that for simplicity.

You see that lots of the base information which is needed to make
good decisions comes from different people: Product managers have a strong idea of how products should be, the technical project manager knows about dates and technical possibilities and can plan with the engineering managers how that can be achieved with the given amount of people in a given time frame. Technical feasibility is worked out with the developers as they’re the experts. The colored arrows try to visualize the communication ways, different colors mark different topics.

Since we work with the communities we have more input of information: The user community tells what is needed and the upstream communities announce what they plan to do by when.

The part with the internal decision taking is very much based on Fate in the Linux part of Novell and that is working fine. Features come in by a requester and all involved parts can give their thoughts in  a discussion forum. The key functionalities add their priority for the feature and finally PM and TPM come to a decision. Features with a high priority have to make it into the product. Engineering managers can assign developers and they can mark features as finished. All the processes are covered by a set of configurable rules. The Fate system is integrated into other infrastructure parts. There are several clients for different needs, the most mature is the KDE fat client.

What is not yet optimal are two things: There is no good way yet for the user community to community their wishes for upcoming products. We are facing that with opening up a new web based openSUSE Fate client soon. That will involve the user community not only in testing and using the product but already in its planing in a defined way.

A more tricky part is how to involve the upstream communities. It would be great for a Product Manager of a Linux distribution to see the feature plans for upcoming releases of big upstream projects, maybe somehow integrated into the Fate for his product. Would the Fate model as described here in a nutshell suitable for upstream projects?

For example, could KDE or GNOME make use of parts of the process for them internally and provide a structured interface to the downstream parties? If so, that could add a lot of transparency. Transparency is the precondition for flexibility and trust and as a result for better collaboration which would benefit all.

I hope that helps for a basic understanding and would love to hear your opinion. I promise to come up with more information about the Fate system and improve my drawing skills