On 02/12/2015 12:47 PM, Chris Hoge wrote: > In the most recent Defcore committee meeting we discussed the need > for a repository to host artifacts related to the Defcore process[1]. > These artifacts will include documentation of the Defcore process, > lists of advisory and required capabilities for releases, and useful > tools and instructions for configuring and testing clouds against the > capability lists. > > One of our goals is increased community awareness and participation > around the process, and we feel that a Gerrit backed repository helps > to achieve this goal by providing a well understood mechanism for > community members to comment on policies and capabilities before they > are merged. For members of the community who aren’t familiar with the > Gerrit workflow, I would be more than happy to help them out with > understanding the process or acting as a proxy for their comments and > concerns. > > We're proposing to host the repository at openstack/defcore, as this > is work being done by a board-backed committee with cross cutting > concerns for all OpenStack projects. All projects are owned by some > parent organization within the OpenStack community. One possiblility > for ownership that we considered was the Technical Committee, with > precedent set by the ownership of the API Working Group > repository[2]. However, we felt that there is a need to allow for > projects that are owned by the Board, and are also proposing a new > Board ownership group. > > The core reviewers of the repository will be the Defcore Committee > co-chairs, with additional core members added at the discretion of > board members leading the committee.
+1 to using the openstack namespace, and having it explicitly listed as a board owned repository. Having it listed as a TC owned repository would be quite confusing since the TC does not own any part of the process. I'd also expect concerns about that confusion from both board and TC members. > In the coming weeks we're going to be working hard on defining new > capabilities for the Icehouse, Juno, and future releases. We're > looking forward to meeting with the developer and operator community > to help define the new capabilities with an eye towards > interoperability across the entire OpenStack ecosystem. The creation > of this repository is an important step in that direction. I'm a bit concerned about the amount of manual effort needed to define capabilities for each release over the long term. It seems like there is an opportunity for some close collaboration between the defcore group and tempest (and whatever other test source defcore wants to draw from) to have test grouping metadata maintained along side the tests and updated as tests are added/changed/removed over time. Then for each release, defcore could extract that information and then do its magic to decide which ones to use. -- Russell Bryant __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
