Home Home > 2013 > 08
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 August, 2013

The openSUSE Release process

August 29th, 2013 by

Michal “|Miska|” Hrusecky writes this week about the openSUSE release process. He gave a talk about this subject at the openSUSE conference this year and the content of this talk is reproduced below (the marketing section, just like with the presentation, is by Jos Poortvliet).

Release Process

To get openSUSE out is a lot of work. We already shared part of what we are doing to keep Factory rolling. But as you can guess, there is much more to it. But let’s pretend it is a simple three-step process:

Step one: developing Factory

When release openSUSE, we immediately start working on the next version: a never ending story. First thing that happens during a new release cycle is coolo announcing the road map. This is the schedule of the release and important checkpoints that we have to reach on our way. After the release Factory (our development version) is not frozen anymore and people can start submitting new stuff. Usually they go crazy and submit a lot of bleeding edge and experimental packages and quite some parts of Factory will get broken.

Now comes the time for keeping Factory rolling. As one picture can say more than thousand words, take a look at how packages get into factory:

factory

A developer creates a package in his home repository and then sends it to the devel project where it get’s some basic review (depends on how the team is setup there). From there, package goes to the factory, where are several automatic checks (will mention them later) and manual review by review team. Once the package passes all these checks, it gets into Factory. And breaks something else there. So somebody has to branch it, fix it, and go through the same process now with a different package…

We’re working on documenting the Factory development process in a little more detail so you can expect a blog on that subject in the coming months!

Checking up on you…

There are several bots that check packages send to Factory. First is factory-auto, which does some basic checks regarding you spec file, rpmlint warnings and similar. If you pass this quick test, it’s time for more thorough testing. A bot named factory-repo-checker tries to actually install your package in a testing environment to make sure it is possible and it also looks for possible file conflicts, so you wouldn’t overwrite somebody elses package. Last check before a package gets in front of the review team is legal-auto. This one checks the licence (did it change? is it a new package?) and if needed calls in our legal team to take a look at the package. The final step is manual review by members of review team which will try to spot mistakes that automatic checks overlook.

Step two: freezing

We could be breaking and fixing stuff forever, but as we have to release at some point we have to do some freezes. First one is the Toolchain Freeze. When we reach that, no new version of compilers will get in, only fixes. This way the rest can fix all the new compiler warning and errors without fear of getting new ones. Next in the line is Base System Freeze which means frozen kernel, KDE, Gnome, X11 and bellow… All these are core components with many packages depending on them. The rest of packages (after getting fixed/upgraded) gets frozen last with release of Beta 1 when we reach Full Feature Freeze. At that point only fixes go in, no new versions and features or anything else that could break anything.

Step three: branching and selecting an ISO

As we get close to the release, Factory gets branched into separate repository, currently 13.1. Factory then gets unfrozen and starts to live it own life again. The newly born release goes through the last stabilization and deep testing phase (both manual and through openQA). Every automatically build iso gets tested until the Gold Master is selected. Gold Master has to be installable andcannot contain any critical ship stopper bugs. It still can contain known bugs, we would never release if we would wait for bug free release. But all these bugs can be fixed via updates and some of them will even get fixed before official release date. After selecting Gold Master it takes us usually about a week to get it synchronized to our mirrors and to get everything ready for the big day. In that time, developers keeps fixing bugs and when you get our fresh release, we already have many fixes ready and waiting.

what I think I do marketing

Marketing process

Let’s talk release marketing now. We’ve got a HUGE list of things we work on in the marketing team.

Building excitement

There is preparation for the release, stuff we do usually in the 2 months before the release. Think about material like the release counters, posters and badges for on websites or at conferences; writing the sneak peek articles and organizing release parties.

Releasing openSUSE

Then there is the release marketing itself. We write a feature guide, extract feature highlights, create screen shots, write announcements for our news site and for the press. Then we put all of the above, combined with a list of people to be interviewed and a link to the gold master into a press kit we send one week before the release to journalists. This way we can have reviews published on the release date.
the braindumptruck

How it all comes about

All that is essentially build upon the list of new features for openSUSE. We gather the developers’ brain dumps at this wiki page. They share with us a bullet list of what changed since the previous release and how important it is for their users.

Pirates

We take these features to a pirate pad and start looking for everything that is missing (which, usually, is a lot: much of the features we don’t know about because developers don’t tell us). We gather info from the sites of projects like KDE and GNOME about their new versions and put it in. We work on the bullet points to make pretty text and we try to bring in some structure.

Once it is reasonably complete, we move it to a wiki page where we start to polish it up and add screenshots, links and video’s if we have em. The end result you are probably familiar with: the Features page. Note that most of this does not really need much experience, almost anybody can help!
Feature guide writing process

Highlighting

Then the next step is to look at that draft and the structure it has gotten and put in some deep thinking to pick the major features for the highlights. There is a lot of whiteboarding in this step: figuring out what the message of our release is, the theme, that is not easy.

These are the main part of the announcement and everything else, which is then ‘just’ hard work – a lot of it. This step needs the most experienced writing and a lot of feedback-improvement-feedback-improvement cycles.

Timeline: work gets crazy at Beta

The biggest problem with all this is that it can’t be done in a very relaxed way because we’re in a hurry. Beta 1 is about 6 weeks before we have the Goldmaster! When the Goldmaster is done, we need to send our stuff out to the press. At that point we can make only VERY minor changes. After all – just a week later we do the release. In that week, we only write social media messages (and translations) and get our websites, servers and everything else in order. Marketing is ready for the release!

Releasing a conclusion

We hope the above gives some sense of how the openSUSE release process works. Yes, it is long, laborious, but also a lot of fun! And of course it results in the awesome operating system which is openSUSE!

dister-mechanic-small

Weekly statistics

And it is that time again: the unveiling of our statistics of openSUSE top contributors of the last week! Here’s the top-ten most active Factory hackers:

Spot Name
1 Dominique Leuenberger
2 Michal Vyskocil
3 Bjørn Lie
4 Tomáš Chvátal
5 Ismail Donmez
6 Hrvoje Senjan
7 Andrey Karepin
8 Vitezslav Cizek, Ludwig Nussel
9 Cristian Rodríguez
10 Todd R, Hillwood Yang

More on Statistics

August 23rd, 2013 by

Shortly before the openSUSE Conference, we featured a post about openSUSE statistics. It mostly talked about where we got the numbers, teasing that we’d share the details at the openSUSE Conference. And Alberto did. Today we’ll bring you the numbers Alberto did digested in images and text.

Downloads and users

The simplest statistics for a Linux distribution are of course the numbers of downloads and users, so let’s start there.

ISO downloads

The methodology used to count downloads is easy to understand: we count every IP address that hit the server or is redirected to one of the mirrors, and express the intention to start downloading one of the ISO images available for the distribution. In this way, we count independently every download that uses the same proxy and every different product downloaded by the same IP. We can group the downloads by weeks or by month. In both images we can see that we started counting in 2010 and we covered openSUSE 11.0 to 12.3. Also, in both graphs we can see what events explain the peaks, like the release of the distribution.

Downloads per month

Downloads per month

Downloads per week

Downloads per week

To make a more detailed analysis we need to concentrate on the monthly graph. For this plot we calculated a linear regression model using the monthly data (41 samples). In the graph you can see a slight growth but decreasing impact of releases. Extrapolating, we can expect about 560K downloads per month in 2014. Note that this is downloads, not installs! Let’s talk about those next.

Installations

To get a more reliable estimation of persistent installations we count systems that regularly update. A count of the encountered unique systems per week or per month is a fair estimator of the number of active installations (see details on the counting).
updates per month

updates per week

Updates per week

Here you see many interesting things. For example, the red trace on top of the plot in 2010 and 2011 are Factory users. If you look closely, you also see that usage of a particular version already starts before it is out – that is due to testers checking out milestones, Beta and RC versions. And you notice how long it takes some users to move over to new versions of openSUSE – not only has over half of our users not moved to the latest 12.3 yet, but about 140.000 users happily still run releases from before 12.2, most of which (except 11.4) receive no security updates!

When we plot a linear regression model on this data, we see a less encouraging picture compared to the downloads: on average, we lose around 300 users per month. On the size of our installed base this is not huge, but worrying nonetheless.

More data

There are more things that we can learn from the data. We can analyze the behavior of users according to the installation medium or the architecture used and in time we can perhaps analyse how repositories are used and which are popular.

Medium and Architecture per week

Medium and Architecture per week

The Open Build Service

The Open Build Service is what openSUSE uses to build and distribute packages. It is a very integral part of our infrastructure and how we work, and its server logs contain a wealth of information on the work done on openSUSE. For example, mining the list of Submit Requests that go into Factory and devel projects, we created the graph below to give an idea of the development of the number of contributors working on openSUSE, with the total (blue) per month going nicely up as you can see.

OBS Contributor Data

Social media

Thanks to the help of Athanasios-Ilias Rousinopoulos (that is a link to his presentation at oSC13) we’re regularly gathering statistics on our social media, a summary you can see in the graph below. Yes, we’re doing well getting our message to people, thank you all for your part in that!

social media data

Let’s compare: openSUSE vs. Fedora

Numbers are useless if you can’t compare. We searched for data from other distributions like Ubuntu, Gentoo, Arch or Debian, but only Fedora provides real numbers with the methodology used to generate them. Kudos to our friends at Fedora for being open and transparent!

Now, they use a different way of gathering data on downloads: counting the number of different IPs seen per day. To count users, they count the number of different IPs seen for this release since the release date. This complicated matters on our side but we’ve made it work. However, one variable was a bit harder: both distributions have different release cycles and dates. As you see in the graphs, we tried our best to make the comparison as direct as possible. The plots below are in the same scale of time and number of downloads.

openSUSE and Fedora Users

openSUSE and Fedora Users

openSUSE and Fedora Downloads

openSUSE and Fedora Downloads

As you can see, Fedora has more downloads than openSUSE. Looking at the users, the situation is reverse: openSUSE has quite a bit more users than Fedora according to this measurement. How is this possible? The explanation is most likely that most openSUSE users upgrade with a ‘zypper dup’ command to the new releases, while Fedora users tend to do a fresh installation. Note that, like everybody else, we’re very much aware of the deceptive nature of statistics: there is always room for mistakes in the analysis of data. To at least provide a way to detect errors and follow the commendable example set by Fedora, here are our data analysis scripts in github.

statistics dister inside close-up

Contributor Statistics for week 33

All these statistics and still we’re not done! Here is the top-10 of contributors to Factory last week. As you can see, Stephan ‘Coolo’ Kulow is on vacation, freeing up a spot in the table 😉

Spot Name
1 Raymond Wooninck
2 Dominique Leuenberger
3 Sascha Peilicke
4 Hans-Peter Jansen
5 Bjørn Lie
6 Dirk Mueller
7 Ladislav Slezak
8 Ismail Donmez
9 Stefan Dirsch, Jan Engelhardt
10 Hrvoje Senjan

On Coordinating our Work

August 15th, 2013 by
Redmine in action

Redmine in action

This week we present Ancor Gonzales Sosa who writes about how we coordinate our work and introduces progress.opensuse.org!

A distributed team

The openSUSE Team at SUSE is a combat force spread all over the world: we have members in Berlin, Prague, Malaga, Nuremberg and Taiwan. And we are planning to reach new territories in the following months (beware, a openSUSE Team member could be standing behind you just right now). Coordinating the work of a distributed team is not always easy. On the other hand, we are disperse not only from a physical point of view, we also work simultaneously in a lot of different tasks and projects. We also have members with different skills and interactions with SUSE employees and community members outside our team. (more…)

Proprietary AMD/ATI Catalyst fglrx 13.8 BETA1 (13.20.5-1) rpm released

August 15th, 2013 by

Notice

This release concern only owners of radeon HD5xxx or above. And adventurous users who know how to deal with troubles.
The majority could easily wait the final release, expected somewhat later.

This is experimental & BETA sofware, it could fix issues you encountered, but also can eat your kitten. You’ve been warned !
But good reports have been collected around, especially with never 3.10x kernel series.

Installing the new repository

Admitting you’ve the normal repository named FGLRX, (use zypper lr -d to find the number or name you give it). You have to start by disabling it, so you could fallback to it quickly. Open a root console or add sudo at your convenience and issue the following command:

zypper mr -dR FGLRX

The beta driver is available for 11.4 (evergreen kernel), 12.1, 12.2, 12.3, 13.1, Tumbleweed (12.3 based + kernel 3.10) at amd-fglrx-beta

To add another repository in the same console as root issue the following command which will install normally the right repository for your distribution

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/amd-fglrx-beta/openSUSE_`lsb-release -r | awk '{print $2}'` FGLRX-BETA

If you are using Tumbleweed use this one

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/amd-fglrx-beta/openSUSE_Tumbleweed FGLRX-BETA

Now the update/upgrade process

zypper dup -r FGLRX-BETA

Let the system upgrade the package, and try to enjoy the new beta

(more…)

oSC13 – some more details and thoughts

August 13th, 2013 by

While we’re internally working on an openSUSE Conference report, we share a few more thoughts on the event.

Booths

The openSUSE both was located near the reception desk. The booth featured:

  • Merchandise, including fresh 12.3 DVDs, openSUSE flyers, calendars, stickers and bookmarks. The team brought a stack of ‘old’ flyers from Nuremberg which were ordered burned by Jos (who brought new style flyers from Berlin, initially printed for LinuxTag 2013). These old flyers are so outdated, both in terms of artwork and text, that it is pointless to keep giving them out…
  • We are Hiring flyers: Due to the demand of the flyers, we printed 30 more jobs descriptions, all were delivered.
  • The booth was dressed up in the openSUSE booth cloth, had a standing X banner and on the table was one of our big touch screens. The booth cloth and standing X banner were ‘test versions’ for what will probably be included in future Booth Boxes. The designs were temporary, and in case of the table cloth, quite horrible…
  • Last but not least, the booth staff of rotating SUSE employees (rotating shifts) informed visitors of what was going on in the openSUSE world.

Of course there were other booths. Mozilla presented the new Mozilla OS, allowing us to be grabby with two prototype phones; there were KDE and GNOME booths with some merchandising, an Oracle booth where a very knowledgeable Oracle employee answered questions about MySQL and MariaDB. There also was an LPI booth for those hungry for knowledge and an FSFE booth for the hungry-for-freedom folk.

We kind’a like having a booth area for in between the talks. What do you think?

Schedule and content

The openSUSE team organized and gave quite a number of talks and sessions. A quick list:

Future

We plan to increase our efforts especially in training workshops next year as there’s a lot of knowledge in SUSE that should be shared with the community.

We’d again like to thank everybody involved in the booth staffing, talks, workshops and everything else, of course!

Weekly statistics

And as usual, we bring you the top-10 contributors to openSUSE Factory. Great work, all!

Spot Name
1 Raymond Wooninck
2 Ladislav Slezak
3 Peter Trommler
4 Dominique Leuenberger
5 Greg Freemyer
6 Stephan Kulow
7 Sascha Peilicke
8 Simon Lees
9 Hans-Peter Jansen
10 Marcus Meissner

Happy Birthday openSUSE

August 9th, 2013 by
Birthday

By Will Clayton

Happy Birthday openSUSE
Alles Gute zum Geburtstag openSUSE
openSUSE Joyeux anniversaire
openSUSE Feliz Aniversário
Χρόνια Πολλά openSUSE
openSUSE Feliz Cumpleaños
Všechno nejlepší k narozeninám openSUSE
openSUSE祝你生日快樂

openSUSE Conference is Over!

August 2nd, 2013 by

teamwork
So, the openSUSE Conference is well over now and most people must have recovered by now. The Greeks, having a very active openSUSE community, were first to organize an openSUSE Conference outside of the safe SUSE Towns Nuremberg and Prague! With only a little practical help from SUSE, they brought together almost 300 people in Thessaloniki. A stellar job in every way! (more…)