Lwood-20151129

November 30, 2015 at 23:59 · Filed under Lwood, OpenStack

Introduction

Welcome to Last week on OpenStack Dev (“Lwood”) for the week ending 29th November 2015. For more background on Lwood, please refer here.

Basic Stats for week 23rd to 29th November 2015 :

  • ~618 Messages (down about 2% relative to last week)
  • ~184 Threads (down about 3% relative to last week)

Traffic and threads steady despite holidays in some parts of the OpenStack world…

Notable Discussions

Work in progress: Grafana Dashboard for Bugs

Lwood-20151115 mentioned the recently launched http://grafana.openstack.org website and this week there’s a post and proof of concept mockup from Markus Zoeller outlining some work he’s doing towards a bug dashboard for OpenStack projects.  He’s actively soliciting feedback on the proposal and assistance – check it out and pitch in if you can :)

Encouraging first time contributors through special bug tags

Shamail Tahir kicks off an interesting thread about using bug tags to encourage first time contributors.  In essence the idea is to have a specific bug tag (probably a new one) that flags bugs as being suitable for first time contributors.  Some review logic could be added that would reject or at least -1 patch-sets that weren’t from a first time contributor.

A good bit of discussion followed including the suggestion that projects may wish to adopt this and take the idea a little further by having certain bugs defined this way that would also have additional comments in them to help the newcomer know where to go solution wise.

Tweaking the IRC Meeting Infrastructure

Tony Breeds puts forward a very cogent case for making some tweaks to the IRC channels used for OpenStack related meetings.  In short he proposes adding #openstack-meeting-5 and renaming #openstack-meeting-alt to #openstack-meeting-2 (which is what it effectively is anyways)

The proposal was well received it looks like the changes will proceed over the next week or two.

Mitaka 1 Milestone week November 30th – December 4th

Doug Hellmann reminds us that week R-18 (that’s this week) is the Mitaka 1 milestone deadline and provides a hand list of things that projects should be doing in light of this.

Moving to a trusting model ?

Morgan Fainberg puts forward a proposal to subtly alter the social policy that is applied to the permitted relationship between who writes code, who reviews code and who reviews/approves code for inclusion into OpenStack.

As it stands most projects prevent each of these three people being from the same company/organisation – the default is, in a sense, “distrust”.  In his post Adam Young provides a little further context around why the policy was worded the way it was – interestingly it’s as much about protecting employee developers from management pressure as anything else.

Morgan’s proposal is essentially that it be made “ok” for all three kinds of involvement (write code, review code, approve code) to be done by people from the same organisation/company with the acknowledgment that if it is felt this trust is broken, the changes can be reverted and the core status of those involved be reviewed.  a “trust” rather than “distrust” model.

While it’s a longish thread (27 messages at the time of writing) I’d commend it to all involved in OpenStack development and, equally people who manage folk that undertake this work.

Changes to the DocImpact flag

Lana Brindley writes of changes to the DocImpact flag – a flag used by developers to notify the Documentation team when a patch might cause a change in the docs.  

To quote Lana: “TL;DR: In the future, you will need to add a description whenever you add a DocImpact flag in your commit message.”  

The rationale is eminently sensible – providing a description will save the Docs folks having to dig quite so deeply to understand what the actually impact on the documentation will be.

More detail can be found in the original post or the spec.  Significantly, a Jenkins job will test for this and the job will fail if there is no description – so please bear this in mind for future patches.

Process change for closing bugs when patches merge

Doug Hellman advises of some changes to automated behaviours when patches containing “Closes-Bug” are merged.  Such patches will no longer automatically make the patch status update to “Fix Committed” as it’s seemingly been a bit of a wonky part of the release process.

Implications of this likely apply to all OpenStack developers, so if that’s you, please take a few minutes to read Doug’s post…

Releases vs Development Cycle explained in a single post

Succinctly put by Thierry Carrez in this email – worth a quick read but, frankly, tricky to summarise in Lwood in less than several paragraphs by which point you might as well have read his email :)

Midcycle dates and locations

A few more midcycle announcements and one poll this past week

People and Projects

Further Reading & Miscellanea

Don’t forget these excellent sources of OpenStack news :)

This edition of Lwood brought to you by Jeff Beck (Guitar Shop, There and Back, Wired) Jordan Rudess (Rhythm of Time), Herbie Hancock (Cantaloupe Island) amongst other excellent tunes.

Comments are closed.