Tomorrow, Thursday June 7th, the OpenStack community will run a
BugTriage day. Why are we doing this ? What are we going to do ? How can
you participate ?
Bug tracking is an essential part of our development processes.
Well-maintained bug lists help us know the current state of our projects
better, define bugfixing priorities, and identify milestone and
release-critical issues.
The trick is, the bug lists can quickly get unusable if they are not
well-maintained. Most of our core projects managed to keep their bug
lists relevant and current, but the largest ones (Nova and Swift)
allowed some pile-up in the recent months... and that creates a vicious
circle: as the bug tracker becomes less relevant, bugs gets even less
attention, and things get worse.
BugTriage days are a category of
BugDays specifically designed to
break this vicious circle. They were discussed at the Folsom Design
Summit as a way to improve our bug
triaging practice. The idea is to concentrate efforts, for one day, in
making our bug tracker relevant again, and start a virtuous circle of
maintenance instead of of a vicious circle of abandonment.
How are we going to achieve that ? The
BugTriage page on the wiki
describes a set of triaging tasks that we should complete. Task one, for
example, is about confirming incoming, untouched "New" bugs. The goal is
to complete as many tasks as possible. Participants will gather in the
#openstack-bugday IRC channel on Freenode. It starts as soon as
it's Thursday somewhere in the world, and will last as long as it's
still Thursday somewhere. We will track the results of our efforts live
on pretty graphs, to quantify how
well we do.
So please join us tomorrow in that long-overdue Spring cleaning effort,
which will go a long way into making Folsom an awesome OpenStack release
! You can read more about the whole event
here.
A few days after an intense and fruitful OpenStack Design summit, I just
recovered enough from jet lag to deliver my impressions in written form.
We put a lot of smart people into rooms to discuss various subjects
hastily defined while we were busy releasing Essex... and the magic
worked again: open collaboration between developers from competing
companies, strong but always polite technical discussions, lots of
decisions, teams of developers with common interests forming,
duplication of effort avoided...
It's clear that the format (mostly inherited from Ubuntu's Developers
Summits) works very well in our open innovation project: everybody comes
with a plan that is open to modifications and the developers are
empowered with decision making. This makes the design summit sessions
very appealing to developers, turning them into advocates of our
development model in their companies, removing any barriers to
contribution that could be left. Being part of the OpenStack community
is just pleasant !
However this edition was a bit different from previous ones. There were
a lot of signs that our community is maturing. With OpenStack growing,
developers can no longer follow every session and give their opinion on
every subject: they have to pick their fights, and trust the other
developers to come up with the right design in sessions they can't
attend. So sessions had a lot less advice-giving people and a lot more
people actually signing up to do work. The topics were much more
deployers-oriented and much less about changing to the latest shiny
stuff. Even less glamorous sessions like bug triaging, documentation,
internationalization or stable branch maintenance saw a lot a
participants present, and signing up to help.
People realized that OpenStack is here to stay, and that strategic
contributions are necessary for it to reach the final stages of its
long-term world domination plans. When did that switch happen ? A graph
recently published in the community
newsletter shows
the change happening a few months into Essex:
As you can see, people used to care about fixing bugs in spikes around
release times. But starting around November, 2011, we see the bugfixes
curve starting to follow the bugreporting curve more closely.
After the Diablo release I advocated for companies to put their money
where their mouth is and start contributing strategically to
OpenStack.
I'm happy to see that it happened during the Essex cycle, and that the
awesome Design Summit we just had confirms that trend.
In a few days the OpenStack developer community will gather in the heart
of San Francisco for three days of brainstorming and discussions around
the next release cycle of OpenStack projects, code-named "Folsom".
The Design Summit is a key moment for our open innovation community.
This is not a conference with speakers. This is not where a closed
developer group announces to the public the changes they intend to push
to their private "open source" project. We design, discuss and make
decisions at the summit as a community. It's quite uncommon, and that's
what makes us different.
Our (elected) PTLs have final say in case of unsolvable conflicts, but
generally consensus is reached in those face-to-face meetings much more
easily than on mailing-lists. That's why this is a critical moment, and
we need to make the best use of this short time together. Connect with
other people interested to solve the same issues, avoid duplication of
work, and collaborate with developers from all those different companies
on making OpenStack awesome.
We have great brainstorming topics for those three days. Most
tracks already have a tentative
schedule posted at http://folsomdesignsummit2012.sched.org/, although
it's still subject to scheduling changes. If you have a new idea for a
session, it's too late to get in the official tracks, but we provide an
Unconference room for talks that could not fit in the tracks,
last-minute ideas and continuation of discussions. And since we like to
talk about random stuff that matters to us, we will also have 5-min
lightning talks every day after lunch.
Session leads should take the time to view Jim Plamondon's training
video, it's a great
introduction on how to make the most of a session you lead. I hope to
meet all of you in person next week !
Over the last months I've seen more and more tweets and news articles
using the formulation "OpenStack should", as in "OpenStack should
support Amazon APIs since it's the de-facto standard". I think there is
a fundamental misconception there and I'd like to address it.
As a quick aside (and contrary to what the twittersphere sometimes
report), it should be noted that OpenStack Nova always supported the
Amazon EC2 API, and that OpenStack Swift grew an Amazon S3 compatibility
layer last year. That said, I'll be the first to admit that one could
rightfully claim that the AWS API support in OpenStack is in less better
shape than the OpenStack API support. But the reason behind it is not
some "OpenStack strategy", it's a reflection of the participating
companies focus.
OpenStack is a true Open Innovation project. It's a collaboration
ground where multiple companies are free to invest development resources
to care about the stuff that is important to them. It's an influence
game where you need to donate developers to play: OpenStack is the
playing field, not the players that push the ball.
Red Hat cared about QPID support, they fielded developers to make it
happen in OpenStack. EC2 API support is originally in Nova because NASA
cared about it. Then with the increase of Rackspace's influence on the
project, the OpenStack API grew faster. Now with Canonical (and others)
interest, Amazon's API support is getting better. Ultimately, code
talks, and you can make things happen. That's what makes OpenStack so
appealing but also so confusing to the industry.
As "OpenStack", we need to make sure the playing field is level (and
hopefully the Foundation will be set up soon enough to address that) and
that the code is modular and welcoming. But it's up to the participating
companies, which throw development resources at the project, to invest
in what's important for them or their customers. And maintain it over
the long run.
So whenever you say "OpenStack should", ask yourself if you shouldn't
really be saying... [Rackspace, Cisco, HP, IBM, Red Hat...] should. Ask
not what OpenStack can do for you. Ask what you can do for OpenStack.
At the time I'm writing this, we have final release candidates
published for all the components that make up OpenStack 2012.1,
codenamed "Essex":
- OpenStack Compute (Nova), at
RC3
- OpenStack Image Service (Glance), at
RC3
- OpenStack Identity (Keystone), at
RC2
- OpenStack Dashboard (Horizon), at
RC2
- OpenStack Storage (Swift) at version
1.4.8
Unless a critical, last-minute regression is found today in these
proposed packages, they should make up the official OpenStack 2012.1
release tomorrow ! Please check out those tarballs for a last check, and
don't hesitate to ping us on IRC (#openstack-dev @ Freenode) or file
bugs (tagged essec-rc-potential) if you think you can convince us to
reroll.
Those six months have been a long ride, with 139 features added and 1650
bugs fixed, but this is the last mile.
