Merge "Update contributor guide for Ussuri"
This commit is contained in:
commit
7058fac53b
|
@ -55,10 +55,6 @@ downvoted. There is also the :ref:`code-review`. Once you have some
|
||||||
understanding, start reviewing patches. It's OK to ask people to explain things
|
understanding, start reviewing patches. It's OK to ask people to explain things
|
||||||
you don't understand. It's also OK to see some potential problems but put a +0.
|
you don't understand. It's also OK to see some potential problems but put a +0.
|
||||||
|
|
||||||
Another way is to look for a subteam you'd like to get involved with and review
|
|
||||||
their patches. See:
|
|
||||||
https://etherpad.openstack.org/p/train-nova-subteam-tracking
|
|
||||||
|
|
||||||
Once you're ready to write code, take a look at some of the work already marked
|
Once you're ready to write code, take a look at some of the work already marked
|
||||||
as low-hanging fruit:
|
as low-hanging fruit:
|
||||||
|
|
||||||
|
@ -215,15 +211,16 @@ really helps you:
|
||||||
|
|
||||||
- Doing more reviews, and seeing what other reviewers notice, will help
|
- Doing more reviews, and seeing what other reviewers notice, will help
|
||||||
you better understand what is expected of code that gets merged into
|
you better understand what is expected of code that gets merged into
|
||||||
master
|
master.
|
||||||
- Having more non-core people do great reviews, leaves less review work
|
- Having more non-core people do great reviews, leaves less review work
|
||||||
for the core reviewers to do, so we are able get more code merged
|
for the core reviewers to do, so we are able get more code merged.
|
||||||
- Empathy is one of the keys to a happy community. If you are used to
|
- Empathy is one of the keys to a happy community. If you are used to
|
||||||
doing code reviews, you will better understand the comments you get
|
doing code reviews, you will better understand the comments you get
|
||||||
when people review your code. As you do more code reviews, and see
|
when people review your code. As you do more code reviews, and see
|
||||||
what others notice, you will get a better idea of what people are
|
what others notice, you will get a better idea of what people are
|
||||||
looking for when then apply a +2 to your code.
|
looking for when then apply a +2 to your code.
|
||||||
- TODO - needs more detail
|
- If you do quality reviews, you'll be noticed and it's more likely
|
||||||
|
you'll get reciprocal eyes on your reviews.
|
||||||
|
|
||||||
What are the most useful types of code review comments? Well here are a
|
What are the most useful types of code review comments? Well here are a
|
||||||
few to the top ones:
|
few to the top ones:
|
||||||
|
@ -264,7 +261,7 @@ reviews:
|
||||||
- Where do I start? What should I review?
|
- Where do I start? What should I review?
|
||||||
|
|
||||||
- There are various tools, but a good place to start is:
|
- There are various tools, but a good place to start is:
|
||||||
https://etherpad.openstack.org/p/train-nova-subteam-tracking
|
https://etherpad.openstack.org/p/nova-runways-ussuri
|
||||||
- Depending on the time in the cycle, it's worth looking at
|
- Depending on the time in the cycle, it's worth looking at
|
||||||
NeedsCodeReview blueprints:
|
NeedsCodeReview blueprints:
|
||||||
https://blueprints.launchpad.net/nova/
|
https://blueprints.launchpad.net/nova/
|
||||||
|
@ -326,7 +323,7 @@ becoming a member of nova-core.
|
||||||
How to do great nova-spec reviews?
|
How to do great nova-spec reviews?
|
||||||
==================================
|
==================================
|
||||||
|
|
||||||
https://specs.openstack.org/openstack/nova-specs/specs/train/template.html
|
https://specs.openstack.org/openstack/nova-specs/specs/ussuri/template.html
|
||||||
|
|
||||||
:doc:`/contributor/blueprints`.
|
:doc:`/contributor/blueprints`.
|
||||||
|
|
||||||
|
|
|
@ -36,8 +36,8 @@ If you are new to Nova, please read this first: :ref:`getting_involved`.
|
||||||
Dates overview
|
Dates overview
|
||||||
==============
|
==============
|
||||||
|
|
||||||
For Train, please see:
|
For Ussuri, please see:
|
||||||
https://wiki.openstack.org/wiki/Nova/Train_Release_Schedule
|
https://wiki.openstack.org/wiki/Nova/Ussuri_Release_Schedule
|
||||||
|
|
||||||
.. note: Throughout this document any link which references the name of a
|
.. note: Throughout this document any link which references the name of a
|
||||||
release cycle in the link can usually be changed to the name of the
|
release cycle in the link can usually be changed to the name of the
|
||||||
|
@ -102,9 +102,9 @@ Why we have a Spec Freeze:
|
||||||
|
|
||||||
By the freeze date, we expect all blueprints that will be approved for the
|
By the freeze date, we expect all blueprints that will be approved for the
|
||||||
cycle to be listed on launchpad and all relevant specs to be merged.
|
cycle to be listed on launchpad and all relevant specs to be merged.
|
||||||
For Train, blueprints can be found at
|
For Ussuri, blueprints can be found at
|
||||||
https://blueprints.launchpad.net/nova/train and specs at
|
https://blueprints.launchpad.net/nova/ussuri and specs at
|
||||||
https://specs.openstack.org/openstack/nova-specs/specs/train/index.html
|
https://specs.openstack.org/openstack/nova-specs/specs/ussuri/index.html
|
||||||
|
|
||||||
Starting with Liberty, we are keeping a backlog open for submission at all
|
Starting with Liberty, we are keeping a backlog open for submission at all
|
||||||
times.
|
times.
|
||||||
|
@ -125,59 +125,6 @@ yourself available to discuss the blueprint, or alternatively make your
|
||||||
case on the ML before the meeting):
|
case on the ML before the meeting):
|
||||||
https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
|
https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
|
||||||
|
|
||||||
Non-priority Feature Freeze
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
This is a Nova specific process.
|
|
||||||
|
|
||||||
This only applies to low priority blueprints in this list:
|
|
||||||
https://blueprints.launchpad.net/nova/train
|
|
||||||
|
|
||||||
We currently have a very finite amount of review bandwidth. In order to
|
|
||||||
make code review time for the agreed community wide priorities, we have
|
|
||||||
to not do some other things. In each cycle, milestones are used to bound
|
|
||||||
when certain types of work will be active and reviewed and to avoid crushing
|
|
||||||
the gate with too much code near the end of the cycle.
|
|
||||||
|
|
||||||
For example, in the Liberty cycle, we reserved the liberty-3 milestone for
|
|
||||||
priority features and bug fixes and did not merge any non-priority things
|
|
||||||
during liberty-3. This meant that liberty-2 was the "Feature Freeze" for
|
|
||||||
blueprints that were not a priority for the Liberty cycle.
|
|
||||||
|
|
||||||
You can see the list of priorities for each release:
|
|
||||||
http://specs.openstack.org/openstack/nova-specs/#priorities
|
|
||||||
|
|
||||||
For things that are very close to merging, it's possible to request an
|
|
||||||
exception for one week after the freeze date, given the patches get
|
|
||||||
enough +2s from the core team to get the code merged. But we expect this
|
|
||||||
list to be zero, if everything goes to plan (no massive gate failures,
|
|
||||||
etc). For history of the process see:
|
|
||||||
http://lists.openstack.org/pipermail/openstack-dev/2015-July/070920.html
|
|
||||||
|
|
||||||
Exception process:
|
|
||||||
|
|
||||||
- Please add request in here:
|
|
||||||
https://etherpad.openstack.org/p/train-nova-non-priority-feature-freeze
|
|
||||||
(ideally with core reviewers to sponsor your patch, normally the
|
|
||||||
folks who have already viewed those patches)
|
|
||||||
- make sure you make your request before the end of the feature freeze
|
|
||||||
exception period
|
|
||||||
- nova-drivers will meet to decide what gets an exception (for some history
|
|
||||||
see:
|
|
||||||
http://lists.openstack.org/pipermail/openstack-dev/2015-February/056208.html)
|
|
||||||
- an initial list of exceptions (probably just a `PTL`_ compiled list at
|
|
||||||
that point) will be available for discussion during the next Nova meeting
|
|
||||||
- the aim is to merge the code for all exceptions early in the following week
|
|
||||||
|
|
||||||
Alternatives:
|
|
||||||
|
|
||||||
- It was hoped to make this a continuous process using "slots" to
|
|
||||||
control what gets reviewed, but this was rejected by the community
|
|
||||||
when it was last discussed. There is hope this can be resurrected to
|
|
||||||
avoid the "lumpy" nature of this process.
|
|
||||||
- Currently the runways/kanban ideas are blocked on us adopting
|
|
||||||
something like phabricator that could support such workflows
|
|
||||||
|
|
||||||
String Freeze
|
String Freeze
|
||||||
~~~~~~~~~~~~~
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -382,8 +329,6 @@ blueprint-only features:
|
||||||
For blueprint and spec features, do everything for blueprint-only
|
For blueprint and spec features, do everything for blueprint-only
|
||||||
features and also:
|
features and also:
|
||||||
|
|
||||||
- If it's a project or subteam priority, add it to:
|
|
||||||
https://etherpad.openstack.org/p/train-nova-subteam-tracking
|
|
||||||
- Ensure your spec is approved for the current release cycle.
|
- Ensure your spec is approved for the current release cycle.
|
||||||
|
|
||||||
If your code is a project or subteam priority, the cores interested in
|
If your code is a project or subteam priority, the cores interested in
|
||||||
|
@ -786,13 +731,9 @@ merge greater strength. In addition, having the subteam focus review efforts
|
||||||
on a subset of patches should help concentrate the nova-core reviews they
|
on a subset of patches should help concentrate the nova-core reviews they
|
||||||
get, and increase the velocity of getting code merged.
|
get, and increase the velocity of getting code merged.
|
||||||
|
|
||||||
The first part is for subgroups to show they can do a great job of
|
Ideally this would be done with gerrit user "tags".
|
||||||
recommending patches. This is starting in here:
|
There are some investigations by sdague in how feasible it would be to add
|
||||||
https://etherpad.openstack.org/p/train-nova-subteam-tracking
|
tags to gerrit.
|
||||||
|
|
||||||
Ideally this would be done with gerrit user "tags" rather than an
|
|
||||||
etherpad. There are some investigations by sdague in how feasible it
|
|
||||||
would be to add tags to gerrit.
|
|
||||||
|
|
||||||
Stop having to submit a spec for each release
|
Stop having to submit a spec for each release
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
Loading…
Reference in New Issue