KDE:Unstable:SC is moving forward

For some time now, the KDE:Unstable:SC repository for openSUSE did not offer any new snapshot due to the work that was going into getting KDE 4.10 into the upcoming openSUSE 12.3 release. Now that the latest KDE 4.10 Release Candidate (RC2) was placed into the correct repositories, I found some time again to update the KDE:Unstable:SC to a new snapshot from KDE git-master (KDE 4.11). Of course at this moment not many changes are happening in git-master due to the polishing of the KDE 4.10 release (beginning of February). 

Happy Testing…..

brBoard Elections: openSUSE Release Strategy

As also indicated on my Board Election Platform page (http://en.opensuse.org/openSUSE:Board_election_2012_platform_rwooninck), one of the topics that I would like to change is the strategy plan/release goals for the upcoming openSUSE releases.

The issue as seen by me. 

Currently the strategy plan for the distribution is seen from the outside as handled only by developers or people working with the development version. Although this is not wrong, it ultimately leads to a lack of communication on why certain decisions were taken, or why defaults were changed, and so on. Of course the discussion appear in the open, like in mailing lists, but other forms of communication, like a wiki page describing the goals set for the next release, including the rationale for the changes, is missing. Ultimately this leads to confusions among end-users, and even among contributors, as endless discussions appear often on the mailing lists.

My proposal on how to improve the process

The strategy process can be improved in two areas. The first area is the simpler one, where we should utilize wiki pages to describe the goals set for the next release. Similar to what the KDE organization is doing. On the main wiki page, the teams can list their plans on what they want to achieve or improve in the next openSUSE release. The team could create detailed wiki pages behind those goals and track the progress on the main wiki page. Major changes within the distribution should always have a detailed page where the change is described in more detail and also indicating how it would impact other areas and/or the user.

The second area is how to get to the right strategy plan for the next openSUSE release. We have openFATE where users are registering their requests for changes, but I see no real official follow-up on this. There are quite some discussions per requests, but in the end it is not clear if a request is being implemented or not. Also the requester will never know exactly in which openSUSE release his request might get implemented. Especially in this area a bigger change is required. In a kind of strategy round the outstanding openFATE requests should be evaluated and classified. Classification could be consisting out of:  ”Next Release”, “Future Release”, “Rejected”, “Info required”. Those classified as “Next Release” will be implemented in the upcoming openSUSE release. Those classified as “Future Release” have been accepted, but due to several reason, they can not be implemented in the upcoming release. Similar approached are also being followed by the other distributions.

Let the openSUSE Board campaign begin.

This afternoon the official start of the Campaign week for the openSUSE board was given. In total there are 8 candidates with all good credentials. 

I would like to kick-off my campaign with the following: 

Introduction and Biography 

Most of you will know me as tittiatcoke, but my real name is Raymond Wooninck, 47 years young, holding a Dutch nationality and since 2001 living with my wife and 2 children in Vienna, Austria. 

Professional live

I have been working since 1990 in the IT area. Started out as an Application Manager and climbed up to departmental manager to SAP Technical Consultant. In 2001 I moved to Austria to start working for the second largest Coca-Cola bottler in the world and to support them during the implement of the SAP system. Now 11 years and diverse positions later, I have been assigned to the function of Application Portfolio Manager within the Strategy & Architecture department. While shaping this new role, I found quite some interesting similarities with the role of the openSUSE board as I see it. 

Unix and I

I had my experience with running Minix, SCO Unix and Linux (since kernel v0.12). Got into the distributions and played around with Red Hat, Mandrake and SuSE, but always came back to the SuSE distro. Shortly after that the openSUSE OBS opened (2009) the possibility to create your own packages, I started packaging a couple of KDE utilities and this brought me an invitation to push them to an official KDE repository and to start working together with the openSUSE KDE team (Many thanks to Dirk Mueller and Stephan Binner (Beineri) for that). 

openSUSE work

After my first experiences with the openSUSE OBS, I got more and more involved. Since end 2009 I took the maintainership for the Google opensource browser Chromium. Tried my luck with the integration of Plymouth (bootsplash) into the openSUSE Distro and got rewarded by having Plymouth as the default bootsplash in openSUSE 12.2. Due to reassignments within the official SuSE/openSUSE teams, I became one of the main maintainers of the KDE repositories and am currently maintaining these repo’s together with a great team. One of the last major activities was to ensure that both the Gnome and KDE desktops would function based on the new systemd-logind session manager and remove the ConsoleKit dependency. This work was done in cooperation with the Gnome team, which was another proof that within openSUSE both teams can work together and make great things happen. 

My view

In my view, there is need for improvement in the areas of user-friendliness (including not only use itself, but easiness of adoption, development, and so on) and access to information. Currently the strategy plan for the distribution is seen from outside as handled inly by developers or people working with the development version. Although this is not wrong, it ultimately leads to a lack of communication on why certain decisions were taken, or why defaults were changed, and so on. Of course the discussion appear in the open, like in mailing lists, but other forms of communication, like a wiki page describing the goals set for the next release, including the rationale for the changes, is missing. Ultimately this leads to confusions among end-users, and even among contributors, as endless discussions appear often on the mailing lists.

Role of the board

At the moment the board is hardly visible. Everybody knows that it is there, but we hear or see only very little of it. Also other candidates have already indicated this. 

In my view, the board should become more active in a number of areas. The most profound one being to set the goals/strategy for the next openSUSE release. This is can be easily done by creating the wiki-pages outlines above where based on the openFATE requests, the feature plan is shown. If this is done early enough, our users would have the opportunity to react on it and to increase the usability of the next release. 

Another area is the interaction with the community and to stimulate its members. With the changing role of the openSUSE boosters, some of the major projects (KDE, Gnome, etc) are now 100% depending on community members. This on itself is already a big change and to find enough community members to help out. Together with the new “rules” being setup regarding packaging, patching, etc, it becomes almost impossible to find new people as that people are volunteering for tasks, seeing what is involved and what rules to follow and they disappear. The openSUSE board should take here a more active role in promoting the active participation and rewarding the work that is being done by the community. 

A third area is the involvement of the board in the discussions on the mailing-lists on topics that concerns part of the strategies or decisions around the openSUSE release/distro. Discussion why a certain item was changed or not changes is now done between users and the responsible maintainer. The maintainer currently defends his position and community members are jumping in on either side. I believe that with a different setup of defining the strategy for the next release, the number of these type of discussions should go down. But in the case they still occur the board should intervene and indicate what the agreed/aligned strategy was regarding the topic. This should move the discussion away from a technical point to a strategic discussion. 

Why you should vote for me?

I believe that my strengths lies in my professional background where I am dealing with Application Strategies, Usability, Accessibility every day. Together with my willpower to bring things to an end, would be very beneficial for the board. I believe that I have proven my strengths in the past with my work on the openSUSE KDE desktop experience, the Chromium web browser as part of the standard openSUSE distribution and the integration of plymouth. 

Aims/Goals

If elected to the board

* I will strive to define, align and implement a new strategy process for the openSUSE releases together with the other board members

* I will try to find ways in which the openSUSE board can establish a better communication with its community

Regarding the KDE team

* I will continue to support the team in the best way I can

* I will strive and drive the team to make the best openSUSE KDE desktop experience ever

Chromium moves out and back into the openSUSE OBS

The last week it was a little hectic around the Chromium webbrowser. Initially I announced that the Chromium webbrowser would move from the openSUSE OBS to Packman due to dependencies on ffmpeg. Shortly after my announcement I was contacted by Ludwig Nussel from SUSE with the question what exactly the issue was and if it was not possible to find another solution in order to keep it part of the openSUSE Distribution. 

After my indications Ludwig talked to some SUSE colleagues and the indication was that Chromium had indeed a chance to come back to the Distribution if we just build the opensource ffmpeg codecs. These are the ones that are activated with a standard Chromium browser.  In the past we had this particular library build on Packman, with both the Chromium and Chrome supported codecs. 

The new version of Chromium passed legal review and I am glad to see that Chromium is building and publishing in his old repositories (network:chromium). Due to the changes a new sub packages (chromium-ffmpegsumo) was added that contains the required multimedia library. However to support also the full range of codecs, we still have the chromium-ffmpeg package building on Packman. When you install the chromium-ffmpeg package, the chromium-ffmpegsumo will be deinstalled. 

I know that people might have switched repositories based on my first announcement and that they have to switch back again. But at least this would guarantee updates through the standard maintenance track of the openSUSE Distribution.

Running for the openSUSE Board

Maybe some people already expected this to happen, but for me it is still a surprise that I actually did it. I put myself up as a candidate for the openSUSE Board. 

I started working with Linux since the early days (Kernel v0.12) and have been using openSUSE since 2003.  I joined the openSUSE project about 4 years ago when I submitted my first KDE package. From that moment things went very fast and I am currently the main maintainer for the KDE repositories and maintaining Chromium and the Plymouth bootsplash. One of the next things I want to tackle (package wise) is Dracut 

as an alternative initrd builder. 

My current “day job” is Application Portfolio Manager for a well-known bottling company that focus on the Central and Eastern Europe market. If you look closely at my IRC nick, then you could guess which company it is  In this job I am responsible for setting out the strategy of all Applications used within the company. This ranges from our main Enterprise System (SAP) to desktop tools like collaboration, email, etc. The strategy should e.g. enable Business opportunities to exploit the main Enterprise system further.

If I am elected to the board, then my day job and past IT experience would be a good use. I would like to see the board to set out a new strategy for the openSUSE distribution which makes it possible to enhance our strengths and values. In the past SuSE has established a name for itself and it created some 

great tools, which even now are unmatched. 

Nowadays everything is about Usability and Accessibility. How usable is the software, how accessible is the information, how can I use this program, etc. I would like to extend this principles to the openSUSE project,  

On one hand we need to strengthen the relationship and the communication between the openSUSE community, including people working for SUSE. Only together we can accomplish great things. 

On the other hand we should value our end-users. These users are giving valuable feedback about how they see openSUSE with regards to Usability and Accessibility and their feedback should be incorporate into the final product. This drives the success of a distribution. Too many things out there are already being decided by a handful of people without listening to others. 

It is my opinion that the board should play a big role in both areas and to enable openSUSE to grow. 

My promise to you is that I will do my best to establish the above, If I would be elected. 

Release of openSUSE 12.2 (Plymouth)

IopenSUSE 12.2 got released some days ago and it seems that the plymouth integration is received very well. Even the openSUSE theme got good comments and is seen as sophisticated. This to my big surprise.   But i am very happy about it as that it proofs that we all did a good job. Unfortunately it seems that plymouth in combinztion with NVIDIA chipset can sometimes cause some unpleasant surprises. But lets hope we cn sort this out with the next release.

As that the pressure ix off again, i started to work on updates of KDE:Unstable:SC again. Yesterday kdegames was moved from svn to git and split out in seperate repositories. So a lot of new packages have to be created. Hopefully i can finish this soon, so that i can create a new snapshot this coming weekend.

Also Chromium saw a big chance recently. A couple of builds ago we noticed that chromium started to behave rathar crashy. Investigations showed that the our attempt to build with as much system libraries as possible failed. The chromium developers seemed to hsve r3ached the point where the system libraries are no longer compatible with the ones shipped with the chromium source. So as of two build, Chromium is now switched to utilize its full sourcecode. This resolved the issues and also the wotk required in keeping the opensuse patches up to date.

Plymouth in openSUSE Factory

As some of you know, I have been working on plymouth support in openSUSE. This was a feature that was requested already some time ago, but nobody found the time to actually implement it. 

Since a couple of weeks I have been working on getting plymouth to work and to resolve the known issues. This can be tracked on the following link :  http://en.opensuse.org/openSUSE:Plymouth 

With the help of teammembers of the openSUSE KDE team (tigerfoot, einar77), the issues were resolved and Plymouth got accepted in openSUSE:Factory

To get full support for password requests and displaying text, the initrd was enhanced with some additional libraries and fonts. The luks initrd script was reworked to get plymouth support for the password requests and a patch was submitted to the maintainer of the package cryptsetup. 

The full set of packages (including all the latest patches, etc), can be obtained from the OBS project home:tittiatcoke. Plymouth of course can be directly obtained from Factory. 

I would like to ask everybody to test the new Plymouth packages and to fill bugs for things that are not working or to indicate these on the webpage : http;//en.opensuse.org/openSUSE:Plymouth. 

Currently we are working on the openSUSE branding for Plymouth, so that we can complete the new boot experience. 

KDE:Unstable:SC has become alive again

I know that for quite some time the KDE:Unstable:SC repo didn’t contain any recent snapshots. The repo was used to test the 4.8.0 tarballs and since then no more updates took place. 

However since today that has changed. As of now KDE:Unstable:SC contains a very recent snapshot of the KDE SC 4.9 and the packages got published. As always the target is to provide weekly snapshots of the KDE SC 4.9 and other packages. 

At this moment the kdemultimedia packages (juk, kmix, kio_audiocd, etc) are still on the 4.8.2 level as that the main KDE repository is moved from SVN to GIT. As soon as this has been completed, the packages in KDE:Unstable:SC will be updated with the next possible snapshot. 

I have been running snapshots of KDE 4.9 and I have to say that the stability is quite good. Most of the changes are the rewrite of plasmoids, etc to the new QML language. 

Enjoy!

Chromium browser got accepted into openSUSE:Factory

After maintaining the Chromium browser in the openSUSE Contrib repositories, the last few weeks things got accelerated and as of this moment the Chromium browser has become officially part of openSUSE:Factory (the future 12.1). 

The first step wa taken about 3 – 4 weeks ago when a separate development project was created (network:chromium). From there onwards it was just a matter of getting the package in the right shape for Factory and making sure that all legal and security conditions were met. Those who are tracking the updates of Chromium in this devel repo, might have noticed that a number of rebuilds were triggered for the 16.0.880 version of Chromium. This all had to do to get a single spec-file that would satisfy both Factory requirements but also would be able to build for the older distributions. At this moment this special repository offers builds for 11.3, 11.4, Factory and also for Tumbleweed. 

I am quite proud on this fact and I hope that the openSUSE Chromium users will be happy with this fact. 

At the moment I am preparing an update to the 16.0.891 version and hopefully sometime beginning of next week the new snapshot will become available.

openSUSE KDE:Unstable:SC repo becomes Trunk again !

A little warning to those that have switched over to the KDE:Unstable:SC repo. The target is that either tonight or tomorrow a new Trunk snapshot will be loaded in this repo. That would mean that the Unstable becomes unstable again  

I have already been building a number of snapshots based on the opened KDE 4.7 trunk and have to admit that things are still looking very stable and even kdebindings is compiling well  

But this might of course change from the moment that KDE 4.6 has been released and the focus shifts to the newer 4.7 release. 

I will keep you posted on the developments around this repository, but this would be the moment to switch over to KDE:Distro:Factory if you want to get the RC1, RC2 and KDE 4.6 final version for your openSUSE system.  Currently it contains RC1, but this would change in the next few days once RC2 is released.