October 30th, 2013 — 7:47pm
OpenStack Compute Tech Lead Russell Bryant has triggered an important discussion on the OpenStack Development mailing list about the process to review blueprints. The Blueprints wiki page currently assigns to Project Tech Leads the task of assigning priority to the blueprints and Russell is suggesting that a wider group of people in the community shares such responsibility..
Blueprints are used by project leaders to track development of significant features in all OpenStack programs: a blueprint is made of a title and a brief description, plus a URL to a wider description of architecture and specifications (usually a wiki or etherpad page). Given the growing size of OpenStack code base, scaling development operations is increasingly hard and one person cannot handle reviewing all the proposed blueprints and set priorities in a way that guarantees finalization.
This brings us to the second issue that needs to be addressed: managing expectations of new contributors. With so many blueprints being proposed it’s hard for a PTL to be accountable for developers to deliver the code based on blueprint’s priorities. Since the PTL used to set the priority for the blueprint, it is hard to held him/her accountable when the code is not delivered accordingly. There is clearly a separation of powers between the person evaluating the blueprints, the developers that will implement them and the reviewers that will review the code submitted.
Russell’s proposal is to assign the responsibility to review the blueprints to the same team of people that will be responsible for reviewing and approving the code during the implementation phase, the core reviewers. The role of the PTL will still be to set the deadlines for the blueprints and to make sure that the roadmap for the program is sound. The core reviewers will then be sharing with the PTL the responsibility and accountability for the deliverables at each release milestone
In the discussion that’s following on the mailing list there are also proposals to include user input while setting the priorities for blueprints. There are risks also associated with this setup. So far, the process has been discussed only taking into account the needs of OpenStack Compute. The project is the largest OpenStack project by number of blueprints, making it the first to need reviewing the existing process. However, the expectation is that several other OpenStack projects may evolve to this point in the future and this is an important test for that time. As such, we welcome holistic feedback: join the discussion on the development mailing list and in Hong Kong.
Comment » | Development, Governance, Measurement
April 26th, 2013 — 7:00am
Special post-Summit issue
Howto get started with all the tooling and setup needed to build, review, and contribute to OpenStack Documentation. By Joe Heck.
The site at http://api.openstack.org is a collection of HTML pages, and one page has an especially interesting story about how it is built. Anne Gentle reveals the secret.
John Bresnahan argues that concepts of data transfer and data storage should not be conflated into a single solution. He believes that OpenStack can benefit from a new component that offloads the burden of optimally transferring images from existing components like nova-compute and swift.
Report from Previous Events
Tips and Tricks
- OpenStack meeting in Cologne May 04, 2013 – Cologne, Germany Details
- OpenStack DACH Day May 24, 2013 – Berlin Fairgrounds Details
- OpenStack Israel May 27, 2013 – Tel-Aviv, Israel Details
- OpenStack CEE Day May 29, 2013 – Budapest Details
- Building an OpenStack Cloud May 30, 2013 – Chicago, IL Details
- OpenStack meeting in Munich Jun 11, 2013 – Munich, Germany Details
- GigaOM Structure Jun 19 – 20, 2013 – San Francisco, CA Details
- OSCON 2013 Jul 22 – 26, 2013 – Portland, OR Details
Welcome New Developers
- Tilottama Gaat, Rackspace
- Zang MingJie, None
- Jason Dunsmore, Rackspace
- James Slagle, None
Ask OpenStack is the go-to destination for OpenStack users. Interesting questions waiting for answers:
The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment.
Comment » | Communication, community, Newsletter
April 11th, 2013 — 2:15pm
I am pleased to announce that a beta release of the OpenStack Activity Board (beta) is now live. The development Activity Board announced few months ago provides a visual overview of all the OpenStack public activity of community members across multiple dimensions: contributors and organizations, projects and tools. From a single interface, you can easily surf OpenStack project content, whether it is coming from the LaunchPad bug tracker, Git or Gerrit, all mapped against the OpenStack Foundation members database.
The Vision Behind the Activity Board
The intention is to give the community a way to answer very precise questions like: who’s contributing to that particular feature of OpenStack? What is that developer/company working on? Which commits/changes are related to a particular bug? Who’s joined the development community recently? With the Activity Board, we have integrated information across the different systems used to develop OpenStack to give corporate and community users a unified view of all the efforts going into OpenStack. There are two main parts of the Activity Board: the Dash and the Insights. The Dash contains reports built by Bitergia using the free software suite MetricsGrimoire, it focuses on trends and quantitative presentation. The Insights, enriched with a semantic layer, powered by zAgile’s open source Wikidsmart adds qualitative details with faceted search of concepts across all the different repositories, tracing people and artifacts across different repositories and bug tracker in order to reconcile people and corresponding contributions.
Looking to the Future
With the integration, we know that we can become a much more efficient project in terms of communicating to members, monitoring our progress, and getting work done. The project is its infancy and we wish to continue to evolve the solution and enhance it with everyone’s feedback. First of all we need you to look at the data and let us know if you find any mistake (we’re keeping a log of known issues). There are a number of areas we want to consider, for example:
- Streamline the faceted search interface according to the community’s desires
- Add more reports based on community requests
- Add integration with other OpenStack project data sources (blueprints, mailing lists, Ask, user groups, IRC)
- Potentially enable interoperability (which is inherent in the Wikidsmart abilities) so that an event in one tool, for example LaunchPad, kicks off another action or update within another tool
- Remove the dependency on Confluence, port the visualization to an open source wiki or portal,
- Publish all the code and tools, integrate the Activity board in the OpenStack infrastructure processes
If you would like to learn more, we are featuring the OpenStack Activity Board in the upcoming events:
I look forward to your comments and further collaboration to make sure this solution benefits the whole community to the maximum extent.
Comment » | Communication, community, Development, Measurement, Tools, Webinar
January 16th, 2012 — 4:37pm
Shine your keyboards, hackers of OpenStack: on February 2nd 2012 you will be called to fight the ever growing number of bugs that keep creeping in our beloved code. On Bug Squashing Day all the OpenStack developer community will focus mainly on Nova to:
- Close old fixed bugs. Old bugs are nasty. Even when they are long dead, they clog bug views and render the lists unusable. Just look at old bugs and check if they still apply ! If they don’t, close them as FixReleased (if you can pinpoint when they were fixed) or Invalid (if you can’t).
- Fix bugs. The best thing you can do on a bug squashing day is to kill a live one. Just look at the list of Confirmed or Triaged and pick your target. Submit a change that fixes it. Ask for review help on the channel.
- Triage incoming bugs. It’s sometimes hard to distinguish fresh bugs from false alarms. You can help by using your expertise or reproduction skills on New bugs. If you can confirm the issue, set the bug to Confirmed. If you can fix it, read the previous chapter. If you need more info from the reporter, set it to Incomplete. And if it happens to not really be valid, set it to Invalid.
You don’t have to be an experienced Nova developer to participate, and we believe that February 2nd will be a great way to get started with the OpenStack community. You can get started by looking at Devstack to build your complete OpenStack development environment. The other projects are welcome to focus on quality that day but Nova is the one that will get more attention.
The event will happen mostly online, in a dedicated #openstack-bugsquash IRC channel on Freenode (that all participants are encouraged to join for the duration of the event). There will also be live meetings in Austin and San Francisco, hosted by Rackspace with food, drinks and games.
Do you want to host a Bug Squash Day on Feb 2nd? Let us know and we’ll add it to the list.
4 comments » | community, Contest, Development, Meetup