Home Home > 2008 > 05 > 21
Sign up | Login

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

Archive for May 21st, 2008

Garden Party

May 21st, 2008 by

Yet again the guardians of the garden are boogieing.

The GNOME Team are holding their meeting tomorrow Thursday 22nd May at 1600GMT/UTC/ZULU (or translate it into your local time). As always you can get sight of the agenda; the main themes for this week are Factory Testing, Bugs – under prioritised/bug voting/10.3 bug squashing, and a new item to the show Community Clinic.

“What pray tell is that last item?” I hear you ask (you did ask didn’t you?).  It is an item aimed at the code contributing challenged.  Basically we hope to be able to provide means for those that are unable to hack (for whatever reason) a way of helping out.  This could be packaging, documentation, pimping our wares and even HALO insertions behind enemy lines for guerrilla hit and run attacks.  Okay maybe not the last item but you get the idea.

So please come along and join the party, you don’t have to BYOB but the more the merrier we become 😀


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?

openSUSE LiveUSB with KIWI

May 21st, 2008 by

liveusb sysinfo

As mentioned on previous post, today I’m playing with LiveUSB creation. Coolo, our lovely (and busy 😉 ) openSUSE project manager discard his experimental test of making LiveUSB due to various specific problem with the USB.

I released factory snapshots of USB and CD images – the USB shows just too many USB specific problems to be worthy, so I kind of decided to kill this idea again ;( More…

Before taking the tutorial mentioned by Luiz Fernando, I’m trying with KIWI LiveUSB stick tutorial. I’ve followed the tutorial last month but the process unfinished yet due to the complaining from KIWI that the image doesn’t fit on my 2 GB USB Flash Disk. At the moment, I was stopped the process and planned to continue after buying another bigger flash disk. I take this conclusion with the assumption KIWI need more than 2 GB of USB disk.

Today I used same tutorial with another assumption 😉 , probably the problem occurred due to the annoying bug with KIWI in earlier version, not with the size of USB disk. KIWI using same image used by LiveCD (about 700 MB), so, 2 GB of USB disk should be fit with the requirement of KIWI for building live USB stick.