Jump to: navigation, search

TripleO

Revision as of 19:26, 27 March 2017 by Bnemec (talk | contribs) (Make subheading smaller than the main page heading. It looks weird to have h1 sub-headings under an h2 top heading.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

TripleO (OpenStack On OpenStack) is a program aimed at installing, upgrading and operating OpenStack clouds using OpenStack's own cloud facilities as the foundations - building on nova, neutron and heat to automate fleet management at datacentre scale.

All documentation including development and deployment can be found at the TripleO Documentation.

Blueprints

All tripleo blueprints. When creating new blueprints please ensure you put 'tripleo' in the short name.

Review team

A handy way to see all the reviews that need action: TripleoO Inbox Dashboard from https://github.com/stackforge/gerrit-dash-creator/

Anyone can do reviews, but only the 'tripleo-core' team can approve them to land. We operate with the OpenStack standard two x +2's except in well, exceptional circumstances. Where multiple people collaborate on a single patch, one of the +2's must come from someone that isn't an author of the patch.

Please don't send requests for reviews to the mailing list. Try IRC or direct email instead. http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html

As a guideline, we follow the standard Review Checklist. We also have an expedited approval process for changes where there is general consensus and only minor implementation changes are needed. Details can be found in the Expedited Approvals Policy.

For specs, we have some additional guidelines Spec Review Policy

The review team should look for reviews in all the following projects:

For completeness, the following URL will show you reviews from the above projects that are open:

If you prefer to see an organized report of Gerrit reviews ordered by Launchpad ticket priority you can use the TripleO ReviewDay

Bug Triage

Triage for us consists of:

  • assigning an importance
  • putting any obvious tags (e.g. 'baremetal') on it (see also: bug tagging policy)
  • setting status to 'triaged'.

(If you're a TripleO contributor and you're filing your own bug, you can skip 'confirm' and go straight to triaged - unless you believe the bug isn't real, in which case why are you filing it? :)

The bug triage team for TripleO is https://launchpad.net/~tripleo.

We're mostly using the process described at https://wiki.openstack.org/wiki/BugTriage, with two key differences:

  • we don't use wishlist: things we'd like to do and things that we do wrong are both defects; except for regressions the priority of the work is not affect by whether we've delivered the the thing or not, and using wishlist just serves to flatten all the priority of all unimplemented things into one bucket: not helpful.
  • we use triaged, not just 'confirmed'.