[OpenStack-DefCore] DefCore Structural: 1. Secretary, 2. Calendar, 3. Decouple Refstack -> DISCUSSIONS / +1s

Rochelle Grober rochelle.grober at huawei.com
Wed Jan 7 01:28:28 UTC 2015


Some thoughts on this summary ( a little backward from the email):

Discussions:  Because I have an internal employee asking me lots of questions about DefCore, I may be a little ahead of the thinking on some of DefCore roadmap.  What I have learned from my discussions, and what I have extrapolated from them is:

DefCore is *NOW* and the board/foundation has to get news and docs out ahead of it.  Because the board *has* approved both Havana Capabilities and Sections definitions, there needs to be:

·         A DefCore Chapter/Wiki tree/html tree/whatever that includes

o   what Defcore is (the official version)

o   The description of DerCore Committee, its structure, its responsibilities, etc

o   Description of DefCore’s work products:  Capabilities, Designated Sections

o   Description of the process for vendors for:

§  Self certification

§  Foundation certification

§  Appeals

§  Waivers

o   A *good* roadmap for where to find the related work products of DefCore:

§  http://git.openstack.org/cgit/stackforge/refstack/tree/defcore

§  havanacore.json

§  havanasections.json

§  How to read/display the files (capabilities tests web page, etc)

§  Icehouse and Juno files when they appear (both draft and final)

o   How to participate in the drafting/final selections for Core for each release

o   A couple of links explaining how OpenSource participation and governance work, both in the general and the specific (few corporate standards folks grasp how the participants are self nominated/elected through the act of participating, or what the codes of conduct are)

o   A FAQ or Ask OpenStack section for DefCore

o   Links to related blogs

·         A news release stating that Havana Core has been approved by the board, that it’s advisory only and pointers to the DefCore documentation.

·         A link to DefCore at or near the top of openstack.org at the bottom of the home page with the other important links

Which brings me to some remarks on item 3, decoupling:

o   The DefCore files that define core need to stay in a git repository, but they need to be controlled by the foundation, and I would think at some point, specifically Legal.  There is currently an openstack/governance repository, but it is for the TCs, which makes sense.  The foundation needs its own for tracking and controlling various code and other documents it needs to own.  For moving Defcore files from draft to approved, it should require two board members (can you say committee cochairs as a possible option?)

o   The reorg of Defcore files out of Refstack would nicely accomplish much of item 3.

o   Which means that the most important aspect of RefStack getting up is the website, with the capabilities report (report page prototype) and some basic words with pointers to the DefCore documentation.

Moving beyond the beginning, there will need to be instructions to find the tests (how to read json, or where to find git.openstack.org, etc), and the various reporting tools, run analysis, etc. that we’ve devised.

Anyway, just some thoughts, but defCore is now *hot* and we need to give people a place to find the information they think they need for it, or persuade them that their thinking needs adjustment.

This is actually getting exciting.

--Rocky



From: Rob Hirschfeld [mailto:rob at zehicle.com]
Sent: Monday, January 05, 2015 12:26 PM
To: defcore-committee at lists.openstack.org; Chris Hoge; Christopher MacGown
Subject: [OpenStack-DefCore] DefCore Structural: 1. Secretary, 2. Calendar, 3. Decouple Refstack -> DISCUSSIONS / +1s


All,



At the last meeting, we committed to having a working session with the Foundation staff and counsel to make some recommendations about structural changes in the DefCore committee that would allow the Foundation to play a larger role in shepherding the process.  This is natural since they are the ones who interact with the vendors and enforce the trademarks.



We covered a lot of ground, I'm going to try and review it as a single email.  I'd like comments so I'm numbering the items for easy reference.



1) Role for Foundation on DefCore



I felt that it was important to have an official role for the Foundation so that meetings and announcements could make official progress even without having one of the Chairs involved.  There is substantial work to be done and we cannot be limited by the schedule of the chairs.  After discussing several options including leaving it ad hoc, everyone on the call agreed that having an official Secretary would address all concerns.  There's an expectation, not a requirement, that the Secretary is also on the Foundation staff.



Since this is internal to the committee, we can act on it immediately.   If you have concerns, please raise this here!  If not, please +1.



> ACTION: Appoint Foundation staffer, Chris Hoge, to be DefCore Secretary for the Scale cycle.



2) Burn Down Calendar for Icehouse & Juno



Companies will want to prepare to make statements in Early April so that Board needs to approve capabilities in early April!  That means we need to target March 3rd to have Juno capabilities in community review!  Ideally, we can mainly focus on deltas from Havana and this work can go quickly.



We considered that it likely practical to review Icehouse and Juno in parallel since they are additive.



> ACTION: Form subcommittee to start capabilities review process.  Coordinated by DefCore Secretary.



3) Decoupling Refstack



DefCore is about defining the tests, not scoring them.  We have clear needs for a project like Refstack to help score vendors and collect usage data, it's not a blocker for our process.  We want to support Refstack; however, we also need to keep DefCore timelines.  For that reason, it's important to acknowledge that DefCore, as approved by the Board, is not dependent on Refstack milestones.



> POSITION: For Scale cycle, vendors can SELF-CERTIFY that they meet the DefCore criteria without any additional validation.  Ideally, we'd have Refstack to allow them to prove compliance; however, we cannot commit to that right now.  Basically, we are agreeing to take vendors at their word at this point.



Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob at rackn.com)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20150107/3c78c7db/attachment-0001.html>


More information about the Defcore-committee mailing list