keynote by Agustin Benito Bethencourt at Akademy

Agustin wanted to talk about success. Times are a tad uncertain now - in the economy, in software and in the KDE ecosystem. It's good to be aware of how well we've been doing over the last 15 years and how well we are positioned for the next decades!

Success story 1

Active patience

We now have an open development process around Qt. Once upon a time, nobody believed that to be even remotely possible - it was not even free software. But we knew how the Qt people wanted the things we wanted and we had the patience to wait and quietly keep pushing. And now - the unexpected happened. This will have a pervasive effect on our infrastructure. We (and others!) can now more easily take Qt in other directions, do new things!

The lesson is, in the words of a Chinese proverb: Be not afraid of growing slowly, be afraid only of standing still.

Success story 2

Magister

KDE is first class in getting new, young people involved and educating them. Our contributors are from a variety of cultures, students or established developers - we all work and learn together. And being involved in KDE you learn a lot. Once you start working in companies you will notice how much you've learned in KDE. And that should make you confident that those who will take over in the future, also part of this community, will be ready for it.

Success story 3

Efficiency

As a 'loose' bunch of volunteers, we're doing incredible work. Most companies in 'our business' do a far worse job at developing products with often far more resources.

Success story 4

Leadership

We're becoming better and better at becoming business incubators. More and more entrepreneurs step up in KDE and start new, cool, innovative businesses. We're proud to be part of a community where innovations can go somewhere!

Success story 5

Vision

We're capable of developing and executing on a vision. Take KDE 4! We've embarked on that vision seven (!!) years ago and today - while it is not perfect yet - we've gotten very close. Most of the plans we decided on are implemented and have come into reality. All that without investments of millions and millions by large companies. We did the impossible!

There are people out there who have their own ideas and projects and who want to be part of KDE, develop under our umbrella, our vision and who join us. This tells us we're on a path to a bright future: we're not just open to people, but there are projects outside who recognize our clear vision and the fact that we deliver.

Success story 6

Experience Innovating
People see how hard it is to stay in the tech business for a long time. You see that with many companies. Yet, we're 15 years old, yet we are still doing new, innovative things. What we do is completely different from what we did, but we still do it with the same spirit and energy than when we started. And Agustin is confident that in 10 years we'll still be approaching entirely new challenges with that same energy!

KDE's future depends basically on US.

These 6 examples (and we haven't even talked about design, the project and code, design or many other things) tell you something about KDE: we have a bright future!

We've gotten to a point in which most limitations we're facing come from inside, things we need to and can change. Not from outside but under our control! There is little out there that can stop us from being successful for another 15 years!

(Agustin holding a Plasma Active tablet) Innovation does happen right here!

Akademy talk about release management

Just watched a talk by Kolabsys dude Jeroen "I have an opinion" van Meeuwen on release management

Jeroen van Meeuwen had some harsh criticism on the way KDE handles Q&A with Bugzilla. He has taken on bugzilla maintainership after someone told him there was no 'single throat to choke', and started to investigate the current state and how it is used by KDE. He presents his findings and suggestions on improvements.

There's no defined process - and that shows. Bugs linger around forever. There are bugs from 2002 which have not been asigned to anyone or confirmed in any way. Worse, the 'final' state we use in KDE, 'resolved', is not, and should not be, the final state of a bug! After fixing a bug, there is testing, confirming and releasing still to do before the bug should be allowed to fall off our radar.

Due to Bugzilla not working as it should, we work with other tools to keep a list of what to do. Reviewboard is an example and many developers have their own list. All that while Bugzilla is more than capable of doing this!

Jeroen talked about how we, as a community, should try to adapt a new process with bugzilla. For that, our setup needs some improvements and he's offering to work on those.

Specifics include having proper types, a 'CLOSED' state and cleaning up products. An example of the latter is that there are two products for 'KMail': 'kmail' and 'kmail2'. Both are open for bug submissions - and there are lots of bugs coming in for the 'old' kmail, adding to the almost 3000 open bugs. However, the developers don't work on kmail anymore: they have all moved to kmail2. How to solve this? Resolve the current unresolved tickets and tell users to move to kmail2. Then close kmail and then move kmail2 to kmail.

Jeroen explained how we can use tools like jared and jenkins to automatically run tests, check if things compile for a certain branch and things like that. How we need to differentiate between Q&A, Triaging, Development and release engineering.

Jeroen proposes to go through the following steps:

• do a bugzilla cleanup
  
  have to contact project developers and ask them what they do with the tickets, then adopt the tickets and setup to that reality.
• formulate and propose standardized use of tickets parameters
  
  help explain how you can use bugzilla as a todo queue
• align documented process and establish responsibilities
• align use of versions/milestones with source code management
• mass-updating tickets through sysadmin requests
• offer one throat to choke

Jeroen realizes he's new to KDE and that he's not the only one who (thinks he) is an expert. Also, KDE works on consensus - so it'll take effort and discussions to get a new way of working in.

There'll be a BOF about QA and triaging on Monday so if you're interested, look at the BoF schedule.

A big take-away from me is that this should actually make development easier, more focussed and more fun - it's not about creating a lot of process to bother developers.

Festa Junina before the BetaPizzaParty?

Lennart "I'm Awesome" Poettering just told us there's Festa Junina going on in Berlin tomorrow. I plan to go there and be back around 5-ish (when the BetaPizzaThing at my place starts).


So if you live in Berlin you're at Ostkreuz around 14:00 and at my place at 17:00 - that's 2 stops with the S-Bahn, to Storkower Strasse, then a short walk to the Eldenaerstrasse: left out the station (seen from the direction you just came, the side of Kaufland); walk to Sconto and go past it, cross then follow the road with a turn to the right. At the next lights you see my walk-in fridge (night shop) and above that I live, nr 28. Hit the bell and I'll let you in (if you know the secret password of course).

Come and have fun ;-)

Future of openSUSE - Update on the Discussion

Beta 2 is out and meanwhile, the discussion on the future of openSUSE development continues. I've attempted to summarize the current status, both to help my own overview of the discussion and to try and help clarify it for others. It has become quite a mail-client-challenging monster thread and Robert S has already asked people to open separate threads for the specifics we're discussing...

Tumbleweed

A first point of consensus was that there should be more emphasis on Tumbleweed. Greg brought up a few pain points he would need to see fixed and asked for help in general. Some conclusions and plans:

• change processes to lower amount of rebuilding of packages in OBS (Greg, Coolo, OBS team)
• add hardware for faster building (OBS team)
• optimize OBS for faster building with things like better/smarter/faster bootstrapping (pre-setup VM's with GCC ?), new filesystem, smarter dependency checking and possibly integrate the rebuild_logic="coolo" thing in OBS itself (OBS team)
• Greg needs to tell us what else we can do to help him make Tumbleweed better

Release Cycle

Consensus seems to be that a longer release cycle is a good idea but nothing concrete has been proposed. Coolo will probably simply make a 12.3 proposal for say November 2013. Some numbers where brought up that show that we can indeed use a longer stabilization period for our releases. 'Release when ready' is also still on the table.

If a longer release cycle is introduced, Tumbleweed becomes more important, but so do the other OBS projects. Users will depend on OBS far more to get new packages. What effect this has and how to tackle that has not been discussed yet. On a personal note, I think the new software.opensuse.org will need some improvements in case we go this route. It would have to put more emphasize on the devel projects as 'official' sources of software. Right now, there are roadblocks put in place for users who want 'stuff from OBS' and it's made clear that things from there are untested and possibly unstable.

Changing the Development Process

Consensus seems to be that the current setup with devel projects feeding into Factory and having groups of maintainers (the aggregate of the individual package maintainers) doesn't work that great. In short, we need to stabilize Factory further. Things that might change:

• Build Failures could create BNC Entries... assigned to the bug owner of the package. (OBS team?)
• Be stricter about maintainership - have 2-3 maintainers who really are responsible. There is some unclarity between the roles of bugowner and maintainer. OBS currently adds the role of maintainer to everyone in a project, which is deemed a bit overzealous - a package can that way end up with 20 maintainers but only 1-2 of these might dare to touch it. Not clear where to go with this yet.
• Do more checks on packages like rebuilding dependencies to see if they fail. Heavily depends on available build capacity (currently very limited). While it requires more work to get something in Factory, as Karl Eichwalder said: "your fun must not prevent the others from having fun."
• process of getting packages in factory might need changes. For less core packages, we could possibly skip devel projects, provided there is review done on the packages. We might also expand devel projects for the remaining packages to do more testing.
• staging projects
  
  
  we could either have one or multiple staging projects.
  • With one, all eyes would be on the same, but it would have the same breakage issues as Factory. Advantage is that we can have an automatic revert policy where packages can't get in Factory until all breakage in Staging is fixed. It would require OBS to automatically detect build errors due to changes in a given package. We're unsure if that is possible.
  • Another way would be to try and get Staging stable, once everything is green - move to Factory. Get new packages, stabilize again, move to factory. Etcetera. Having multiple staging's in parallel might help to lower the 'latency' of getting packages in Factory but it would cost build resources.
  This discussion is also still ongoing.

It was brought up that it'd be possible to create a 'core' of base openSUSE packages (roughly up to X.org) which would be 'atomically updated' for the rest of the packages on top, decreasing breakage and allowing easier testing. This could even be part of a release scheme with a 'core openSUSE' and peripheral packages in Tumbleweed and OBS. It would require some work on the software.openSUSE.org search UI and software management in general, however.

Social issues and responsibilities

Several people brought up the social side of things. As Coolo already mentioned in his initial email, we'd need more people fixing problems 'all over'. These will need mentoring - something openSUSE currently doesn't do in a structured manner, except in the context of Google Summer of Code.

Aside from mentoring, there should be more clarity about responsibilities. If a new version of a library breaks things, who should fix this? The person who maintains the library or the applications which are broken by it? These questions are unanswered as well and possibly a one-size-fits-all answer doesn't exist.

Last but not least, development is helped by a positive, constructive atmosphere on the list. The openSUSE Board has been spending some efforts in improving the situation on our lists and with some success. But more would be needed and how to do this is still unclear.

Conclusion?

It is most certainly not clear where exactly we will end up. Of course, we're only 6 days since the announcement by Coolo that he thinks things have to change. Much of the discussions does point to interesting solutions, but we have to come to definite conclusions before anything can be done. And then, we need people to commit to executing some of the changes!

The openSUSE Conference (Prague, October)will be a good place where we can finalize these conclusions and start implementing things. If you're in the Americas, the openSUSE Summit in Orlando in September might be more convenient for you... In both cases, if you have an interest in the future of openSUSE you should make sure to be there!

Party and Beta

For those organizing something for the openSUSE 12.2 Beta Pizza testing, there is a nice poster you can use! Made by Jürgen Weigert with some help from fellow Geeko's in the NUE office, the source is in Github and you can use it for your own Pizza and Beta event! click here to go to our artwork github repo.

On a related note, the top-ten contributors to openSUSE 12.2 since Beta 1 are:

• Dirk Mueller
• Stephan Kulow
• Marguerite Su
• Marcus Schäfer
• Takashi Iwai
• Ciaran Farrell
• Stefan Dirsch
• Dominique Leuenberger
• Todd rme
• Graham Anderson

Great work all ;-)

This weekend: pizza and beta at my place!

Hi all!

In the spirit of a delayed release and extremely interesting discussions on where openSUSE is going, I'm organizing a BetaPizzaParty at our place in Berlin. It'll be all about eating pizza while testing openSUSE 12.2 Beta 2 and gossiping about what openSUSE is up to lately.

If you want to be there, just say so in the comments ;-)

We'll order pizza (or might make some of our own, I haven't decided yet). And I have some Old Toad left, if you're interested - or we can get some more beer in my walk-in fridge downstairs.

If you don't live close enough by Berlin but want a BetaPizzaParty, see if there is one close to you or organize your own.

And remember - even if you haven't completely understood yet that openSUSE is the coolest Linux distro, you're welcome to join in the celebration, pizza-eating and drinking.

Looking forward to some fun, cu there!

Edit: oh, on a related note, in my enthusiasm I forgot to mention place and date. So let me fix that:

• where: Eldenaerstr 28A, Friedrichshain
• When: Saturday, from 17:00 until we're wasted and pass out.

Edit 2: those at QtContributorSummit are more than welcome to come by earlier on Saturday - check out the place, give us a hug, see popcorn, all that ;-)

edit 3: see here: there's a party BEFORE the party at OstKreuz!

COSCUP - KDE and openSUSE

COSCUP is Taiwan's biggest FOSS tech event, full of exciting technology and great people. As you might know, this year COSCUP will feature a special track dedicated to KDE and openSUSE!

Call for Papers closing!

The call for papers for this Feature track at COSCUP will close in just a few days - June 15 to be exact. So you have to hurry up sending in your proposal - there's a huge audience waiting for your input!

We're still very much looking for subjects including localization and local FOSS community work, packaging and distribution technology, desktop technologies and development, cross-project collaboration and cloud computing tech.

Note that despite the long tradition of close collaboration between KDE and openSUSE, both communities welcome talks not directly related to either of those. KDE on other Linux distributions or non-KDE desktop technologies on openSUSE are very much encouraged to send in proposals too!

Again, the call for papers ends on June 15. Please email a proposal of about 200 words, accompanied by a ~50 word biography, in either English or Chinese, to the Program Committee before that date.

Program Committee

The Program Committee for the KDE/openSUSE track at COSCUP consists of the following people:

• Franklin Weng (KDE)
• Aaron J. Seigo (KDE)
• Sakana (openSUSE)
• Al Cho (openSUSE)
• Bryen Yunashko (openSUSE)
• Greg Kroah-Hartman (the Linux Foundation)

Improved Support for Events

The openSUSE community introduced the Travel Support Program to support travelers to represent openSUSE at conferences and events. A few days ago the team announced a minor change in policy: besides travel costs, the team will also help with costs related to booths, entry tickets and marketing materials.

Entry tickets and booths

While most Free Software events have Free entry - either for everyone or at least for those staffing a booth or giving a talk, this is not always true. Also, some events charge even volunteer organizations for a booth. While we're not too fond of that, reality is one of those things you have to live with and thus this decision - we pay, but up to a reasonable limit.

Marketing materials

Another thing is marketing materials. While we ship tens of thousands of DVD's, flyers, posters and other things around the world each year, sometimes it just doesn't make sense. Sending 100 DVD's with some posters and flyers (worth about 10 bucks) to some countries can easily cost many times the value of what we send. Sometimes, customs give us an extremely hard time and try to charge for the 'value of the software'. In short - we need to be able to produce things locally. And now we can!



The openSUSE ambassadors can pick materials from our well stocked github repo or, of course, modify something there or even create their own.

Now go and spread the word!

Find a little more info in the announcement by the Travel Support Team and of course on the wiki page!

Yup, the travel support program is currently just sponsored by SUSE - we haven't figured out (still, I know) how to take donations from others - yet. But if you want to help out financially, talk to me or the travel support team, I'm sure we can work something out!