Jump to: navigation, search

Difference between revisions of "CrossProjectLiaisons"

(Oslo)
(Oslo)
Line 36: Line 36:
 
| Manila || Thomas Bechtold || toabctl
 
| Manila || Thomas Bechtold || toabctl
 
|-
 
|-
| Murano || Serg Melikyan || sergmelikyan
+
| Murano || Kirill Zaitsev || kzaitsev_
 
|-
 
|-
 
| Neutron || Ihar Hrachyshka || ihrachyshka
 
| Neutron || Ihar Hrachyshka || ihrachyshka

Revision as of 17:35, 21 July 2015

Many of our cross-project teams need focused help for communicating with the other project teams. This page lists the people who have volunteered for that work.

Oslo

There are now more projects consuming code from the Oslo incubator than we have Oslo contributors. That means we are going to need your help to make these migrations happen. We are asking for one person from each project to serve as a liaison between the project and Oslo, and to assist with integrating changes as we move code out of the incubator into libraries.

  • The liaison should be active in the project and familiar with the project-specific requirements for having patches accepted, but does not need to be a core reviewer or the PTL.
  • The liaison should be prepared to assist with writing and reviewing patches in their project as libraries are adopted, and with discussions of API changes to the libraries to make them easier to use within the project.
  • Liaisons should pay attention to [Oslo] tagged messages on the openstack-dev mailing list.
  • It is also useful for liaisons to be able to attend the Oslo team meeting (Meetings/Oslo) to participate in discussions and raise issues for real-time discussion.
Project Liaison IRC Handle
Barbican Douglas Mendizábal redrobot
Ceilometer Julien Danjou jd__
Cinder Jay Bryant jungleboyj
Congress Tim Hinrichs thinrichs
Designate
Glance Louis Taylor kragniz
Heat Thomas Herve therve
Horizon Kirill Zaitsev kzaitsev_
Ironic Lin Tan lintan
Keystone Brant Knudson bknudson
Manila Thomas Bechtold toabctl
Murano Kirill Zaitsev kzaitsev_
Neutron Ihar Hrachyshka ihrachyshka
Nova Victor Stinner haypo
Octavia Michael Johnson johnsom
Sahara Sergey Reshetnyak sreshetnyak
Swift
TripleO Ben Nemec bnemec
Trove Amrith Kumar amrith
Zaqar Flavio Percoco flaper87

Release management

The Release Management Liaison is responsible for communication with the Release Management team, attending the weekly 1:1 syncs in #openstack-relmgr-office, keeping milestone plans up to date, and signing off milestone and release tags. That task has been traditionally filled by the PTL, but they may now delegate this task if they wish.

  • By default, the liaison will be the PTL.
  • The Release Management Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL.
  • The liaison may further delegate work to other subject matter experts
Project Liaison IRC Handle
Nova John Garbutt johnthetubaguy
Cinder Mike Perez thingee
Swift John Dickinson notmyname
Neutron Kyle Mestery mestery
Keystone Morgan Fainberg morganfainberg
Horizon David Lyle david-lyle
Glance Nikhil Komawar nikhil_k
Ceilometer gordon chung gordc
Heat Angus Salkeld asalkeld
Oslo Doug Hellmann dhellmann
Trove Nikhil Manchanda SlickNik
Sahara Sergey Lukjanov SergeyLukjanov
Ironic Devananda Van der Veen devananda
Zaqar
Designate
Barbican Douglas Mendizábal redrobot
Manila Ben Swartzlander bswartz
Murano Serg Melikyan sergmelikyan
Congress Tim Hinrichs thinrichs

QA

There are now more projects that are being tested by Tempest, and Grenade or a part deployable by Devstack than we have QA contributors. That means we are going to need your help to keep on top of everything. We are asking for one person from each project to serve as a liaison between the project and QA, and to assist with integrating changes as we move forward.

The liaison should be a core reviewer for the project, but does not need to be the PTL. The liaison should be prepared to assist with writing and reviewing patches that interact with their project, and with discussions of changes to the QA projects to make them easier to use within the project.

Project Liaison IRC Handle
Nova Matt Riedemann mriedem
Cinder
Swift
Neutron Salvatore Orlando salv-orlando
Keystone David Stanek dstanek
Horizon
Glance
Ceilometer Chris Dent cdent
Heat Steve Baker stevebaker
Oslo Davanum Srinivas dims
Trove Nikhil Manchanda and Peter Stachowski SlickNik and peterstac
Sahara Luigi Toscano and Sergey Lukjanov tosky and SergeyLukjanov
Ironic Adam Gandelman adam_g
Zaqar
Barbican Steve Heyman hockeynut
Manila Valeriy Ponomaryov vponomaryov

Documentation

The OpenStack Documentation is centralized on docs.openstack.org but often there's a need for specialty information when reviewing patches or triaging doc bugs. A doc liaison should be available to triage doc bugs when the docs team members don't know enough to triage accurately, and be added to doc reviews that affect your project. You'd be notified through email when you're added either to a doc bug or a doc review. We also would appreciate attendance at the weekly doc team meeting, We meet weekly in #openstack-meeting every Wednesday at alternating times for different timezones:

Project Liaison IRC Handle
Nova Joe Gordon or Michael Still Jog0 or mikal
Cinder Mike Perez thingee
Swift Atul Jha or Chuck Thier koolhead or creight
Neutron Edgar Magana emagana
Keystone Steve Martinelli stevemar
Horizon Rob Cresswell robcresswell
Glance Brian Rosmaita rosmaita
Ceilometer Ildiko Vancsa ildikov
Heat Randall Burt randallburt
Oslo Doug Hellmann dhellmann
Trove Laurel Michaels, Matt Griffin laurelm mattgriffin
Sahara Chad Roberts crobertsrh
Ironic Mitsuhiro SHIGEMATSU pshige
Zaqar
Barbican Constanze Kratel constanze
Murano Kirill Zaitsev kzaitsev_
Manila

Stable Branch

The Stable Branch Liaison is responsible for making sure backports are proposed for critical issues in their project, and make sure proposed backports are reviewed. They are also the contact point for stable branch release managers around point release times.

  • By default, the liaison will be the PTL.
  • The Stable Branch Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL.
  • The liaison may further delegate work to other subject matter experts
Project Liaison IRC Handle
Ceilometer Eoghan Glynn eglynn
Cinder Jay Bryant jungleboyj
Glance Erno Kuvaja jokke_
Heat Zane Bitter zaneb
Horizon Matthias Runge mrunge
Ironic Adam Gandelman adam_g
Keystone Dolph Mathews dolphm
Murano Kirill Zaitsev kzaitsev_
Neutron Kyle Mestery (Ihar Hrachyshka?) mestery (ihrachyshka?)
Nova
Sahara Sergey Lukjanov SergeyLukjanov
Swift
Trove Amrith Kumar amrith

Vulnerability management

The Vulnerability Management Team needs domain specialists to help assessing the impact of reported issues, coordinate the development of patches, review proposed patches and propose backports. The liaison should be familiar with the Vulnerability Management process and embargo rules, and have a good grasp of security issues in software design.

  • The liaison should be a core reviewer for the project, but does not need to be the PTL.
  • By default, the liaison will be the PTL.
  • The liaison is the first line of contact for the Vulnerability Management team members
  • The liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL
  • The liaison may further delegate work to other subject matter experts
  • The liaison maintains the members of the $PROJECT-coresec team in Launchpad (which can be given access to embargoed vulnerabilities)
Project Liaison IRC Handle
Ceilometer Lianhao Lu or Gordon Chung llu/gordc
Cinder
Glance Stuart McLaren or Nikhil Komawar mclaren or nikhil_k
Heat Steve Hardy shardy
Horizon Lin Hua Cheng lhcheng
Ironic Jim Rollenhagen jroll
Keystone Dolph Mathews dolphm
Neutron Salvatore Orlando salv-orlando
Nova Michael Still mikal
Sahara Michael McCune or Sergey Lukjanov elmiko or SergeyLukjanov
Swift
Trove Nikhil Manchanda SlickNik

API Working Group

The API Working Group seeks API subject matter experts for each project to communicate plans for API updates, review API guidelines with their project's view in mind, and review the API Working Group guidelines as they are drafted. The liaison should be familiar with the project's REST API design and future planning for changes to it.

  • The liaison should be the PTL or whomever they delegate to be their representative
  • The liaison is the first line of contact for the API Working Group team members
  • The liaison may further delegate work to other subject matter experts
  • The liaison should be aware of and engaged in the API Working Group Communication channels
  • The Nova team has been very explicit about how they will liaise with the API Working Group, see the Responsibilities of Liaisons
Project Liaison IRC Handle
Barbican Douglas Mendizábal redrobot
Ceilometer Chris Dent cdent
Cinder Alex Meade ameade
Congress
Designate
Glance Stuart McLaren or Nikhil Komawar mclaren or nikhil_k
Heat Ryan Brown ryansb
Horizon Cindy Lu clu_
Ironic Lucas Alvares Gomes lucasagomes
Keystone Dolph Mathews dolphm
MagnetoDB Ilya Sviridov isviridov
Magnum
Manila Alex Meade ameade
Mistral
Murano
Neutron Salvatore Orlando
Henry Gessau
salv-orlando
HenryG
Nova Matthew Gilliard and Alex Xu gilliard and alex_xu
Rally
Sahara Michael McCune and Sergey Lukjanov elmiko and SergeyLukjanov
Swift John Dickinson notmyname
Trove Peter Stachowski and Amrith Kumar peterstac and amrith
Tripleo
Zaqar Fei Long Wang flwang
Murano Nikolai Staroudbtsev Nikolay_St

Logging Working Group

The Log Working Group seeks experts for each project to assist with making the logging in projects match the new Logging Guidelines

Project Liaison IRC Handle
Glance Erno Kuvaja jokke_
Oslo Doug Hellmann dhellmann
Nova John Garbutt johnthetubaguy
Murano Nikolay Starodubtsev Nikolay_St

Inter-project Liaisons

In some cases, it is useful to have liaisons between projects. For example, it is useful for the Nova and Neutron projects to have liaisons, because the projects have complex interactions and dependencies. Ideally, a cross-project effort should have two members, one from each project, to facilitate communication and knowledge transfer.

Projects Name IRC Handle Role
Nova / Neutron
Sean M. Collins sc68cal Neutron liaison for Nova
Brent Eagles beagles Nova liaison for Neutron
Nova / Glance
Fei Long Wang - Glance liaison for Nova
Jay Pipes jaypipes Nova liaison for Glance
Nova / Ironic John Villalovos jlvillal Ironic liaison for Nova
Michael Davies mrda Ironic liaison for Nova
Neutron / Ironic
Sukhdev Kapur sukhdev Neutron liaison for Ironic
Mitsuhiro SHIGEMATSU and Jim Rollenhagen pshige and jroll Ironic liaison for Neutron

Etherpads

The following is a list of etherpads that are used for inter-project liaisons, and are continuously updated.

Nova - Neutron: https://etherpad.openstack.org/p/nova-neutron