Archive for September, 2011

﻿At the openSUSE conference last week, Lydia Pintscher from the KDE Community Working Group led a BoF on “women in openSUSE”. This is what we (Stella, Bruno, Lydia, Pascal, Susanne, Greg) worked out:

There are very few women in openSUSE for a variety of reasons. In our perceiption, despite the good efforts of moderators on IRC, forums and mailing-lists, some attitudes there still persist, and we believe these are a key issue that keeps women away. To further address this as a small group, we decided to start at just one place, opensuse-project@. Here’s why and how:

There is quite some research on why there is so few “women in FLOSS” in general. One of the recurring topics there, and one that we also quickly came to in the BoF, was the ‘flaming’, or more generally, the negative possibilities of the direct, unfiltered yet anonymous communication on IRC, forums and mail.

We all value the speed and positive directness of those forms of communication — however it’s cutting off facial expression and physical reaction. So it’s very easy to miss the tone, without even noticing. To more sensitive souls, this is creating a barrier of entry that especially women do not want to cross, or if it hits you unprepared, will reject you, often with no return. Nota bene: this effect is not limited to women! It just happens to reject women more than men.

What’s going on there? On one side there is newcomers wanting to learn, and with a great potential to contribute, however with a “thin skin”, an expectation of being treated with respect and politeness, whatever that means. On the other side, there are knowledgeable people, often young, sometimes unpatient, maybe tired, frustrated themselves. Now the former ask naive questions while the latter “shoot out” a quick response without any visual feedback on what happens right after they hit the “send” button. Kazoom! And the frustration results into discussions that quickly are far beyond the original topic, frustrating, unproductive and the opposite of what we want: respect and getting things done.

openSUSE, like many other open source projects, has set the direction for mutual respect by working out Guiding Principles, and making members accept these. The openSUSE project Board is forming a body of volunteers who “enforce” these rules, something like the Community Working Group in the KDE project. The objective is to focus the speed and directness of the communication on productivity: turn the flaming energy of frustrations into creative energy that makes openSUSE a place to enjoy and to contribute to!

We, the BoF participants, want to simply support that effort, by working on just one list (opensuse-project@), and by providing additional material that complements the very high level goals set forth in the guiding principles.

You can now get a decent view of a feature that is adapted for printing. Either click on “Print preview” in your browsers menu, or on “Print” in the feature export box on the right side of your feature.

Adding inline images and screenshots

To add a screenshot or any other image included in your feature, just add a relation with type “url” that points to your image in the net. You can for example upload it to paste.opensuse.org or any other image hoster.

Even if the last news from the Education project is just one month old, many people asked me during the openSUSE Conference why the Education project itself is currently so quiet.

Well, the “problem” is, that our Education team is currently more a team of technical specialists and many work is done behind the scenes without communication to “the outside”. So even if you did not hear from us for some weeks, we are still alive and coding!

Kirill is currently reviewing all 425(!) packages in the Build Service Education project and submitting them to openSUSE Factory afterwards – so openSUSE 12.1 will come with a huge set of packages directly inside the official repository.

Cyberorg is working on the next release of the openSUSE Edu Li-f-e DVD with the LTSP integration.

Anubusg1 and many others (the project currently lists 44 maintainers) are doing the “normal” packaging stuff like upgrading and fixing packages for 12.1 (aka Factory)

The Desktop4Education project from Austria was again present at the Conference and gave a great overview of the current status of the project during their talk. Good to hear that the project is being frequently used as a reference case by the Austrian Federal Ministry for Education, Arts and Culture and as such promoted by them throughout Austria.

Talking with Andre Massing from the Simula Research Laboratory during his talk at the conference was quite interesting. Looks like the Science project might see some very interesting new packages in the next months. During the discussion, we agree that the Education and the Science project can share a lot of efforts in their project setups and organization. But they will stay separated (at least in the Build Service) as their audience is very different, even if they share some packages (which is currently done via links inside the Build Service).

I’m happy to announce LibreOffice 3.4 packages for openSUSE. They are available in the Build Service LibreOffice:Stable project.

LibreOffice 3.4 provides many interesting features and fixes. The openSUSE packages are based on the LibreOffice 3.4.2 release but they include all fixes from the last 3.4.3 bugfix release. Please, look for more details about the openSUSE LibreOffice build on the wiki page.

The openSUSE LO team hopes that you will be happy with this release. Though, any software contains bugs and we kindly ask you to report bugs. It will help us to fix them in the future releases.

Other information and plans:

It took me quite some time to prepare the 3.4 update because the split build was not longer supported and I had to completely rework the packages.

We are going to prepare official maintenance update for openSUSE-11.3 and 11.4. You might expect it within next few weeks.

as you might know I participated in the GSoC this year. When the coding period
started my mentors and I decided to use the “test driven development” (TDD)
approach to develop the python obs library. In the following I’ll summarize
why I think using this approach was a good idea and how it helped me to write
the code.

It helps with designing a class interface
With TDD you usually write the testcases _before_ the actual code. When
doing so you already get a feeling if the design of the interface or method
is practical because you use the interface multiple times in your testcases.
Example:
One of the first coding tasks was to write a class for managing (editing,
saving etc.) project/package xml metadata. For instance a common use case
is to add a new repository the project’s metadata so I wrote a testcase for
it. The first version looked something like this:

(of course the add_* methods aren’t statically coded in the RemoteProject’s
class – instead we use a “ElementFactory” which is returned by an overridden
__getattr__ (for the details have a look at the code:) ))
Without TDD I probably would have implemented the first version and
afterwards I had realized that I didn’t like it…

It helps structuring the code
Let’s consider some “bigger” method which needs quite some logic like
the wc.package.Package class’ update method (the update method is used to
update an osc package working copy). Before writing the testcases I started
to think about how the update method can be structured and what parts can
reside in its own (private) method (probably a natural thing which has
nothing to do with TDD). I ended with the following rough layout:

calculate updateinfo: a method which calculates which files have to be
updated (in particalur it returns an object which encapsulates newly added
filenames, deleted filenames, modified filenames, unchanged filenames etc.)

perform merges: a method which merges the updated remote file with the
local file

perform adds: simply adds the new files to the working copy

perform deletes: deletes local files which don’t exist anymore in the
remote repo

Then I started to write some testcases for the calculate_updateinfo method
and implemented it. Next I wrote testcases for the various different update
scenarios and implemented the methods and so on. It is probably much
easier to write testcases for many small methods than for a few “big” methods.
From time to time I realized that I forgot to test some “special cases”, so
I added a new testcase, fixed the code and ran the testsuite again. The cool
thing is if the testsuite succeeds (that is the fix doesn’t break any of
the existing testcases + the newly added testcase succeeds) one gains
confidence that the fix was “correct”.

It speeds up the actual coding
My overall impression is that TDD “speeds” up the actual coding a bit. While writing
the testcases I also thought how it could be implemented. So when all testcases
were done I had rough blueprint of the method in my mind and “just” transformed
it into code. For instance it didn’t take much time to write the initial
version of calculate_updateinfo method.
But of course this doesn’t work for all methods. Stuff like the Package class’
update method took quite some time (and thinking!) even though I already wrote
some testcases. The main reason was the fact that the update should be
implemented as a single “transaction” (the goal was that the working copy
isn’t corrupted if the update was interrupted). As you can see TDD is no
black magic approach which makes everything easier – thinking is still
required:)

It helps to avoid useless/unused code paths
I just wrote the code to comply with the existing testcases – no other
(optional) features were added. Sometimes I realized that some feature was
missing. In this case I added another testcase and implemented the missing
feature. So the rule was whenever a new feature was required a testcase had to
exist (either a testcase which directly tests the modified method or a testcase
which tests a method which implicitly calls the modified method).

It helps to overcome one’s weaker self
From time to time I had to write some trivial class or method where I
thought it isn’t worth the effort to write testcases for it. A perfectly
prominent example was the wc.package.UnifiedDiff class (it’s only purpose is
to do a “svn diff”-like file diff). At the beginning I wanted to start coding
without writing testcases because I thought it’s enough to test its base class
(that’s the place were the interesting things happen and the rest is just
“presentation/visualization”).
Luckily I abandoned this idea and wrote the testcases. It turned out that it
was a good idea because this “trivial” visualization I had in mind was more
complicated than I initially thought;)
What I learned from this example is that it is most likely better to write
testcases because the class/method might evolve and might get more complicated.

After publishing an article in the openSUSE Wiki (in portuguese sorry) about AR.Drone, I am developing an application to control it using the library opencv computer vision to Processing and using your camera in the operating system openSUSE 11.4. The source code soon in The Open Build Service (OBS), For now, watch the video below of the image HERE.

Dear users of fglrx drivers (pre-packaged or .run installer)
On 19th August I’ve opened a pledge see this article, and I’m give you today a refresh status :

I personally already thanks of the actual donors. You rocks !
We are almost done at today, but almost is not done 🙂
So if you can spread the word a bit more, that’s would be really cool. My objective is been able to give the money back to Sebastian Siebert during our openSUSE conference. And so create a kind of ceremonial.