Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

as you probably know, QoS feature is on horizon for Liberty and uses a
separate feature/qos branch. It's expected that after it's complete,
the branch is merged back into master.

Note that it will probably be the first (or the second, if
feature/pecan goes in before feature/qos) time when a feature branch
is actually merged into master, so we're in an unknown land here, and
I hope everyone involved understands we want to set a good example in
terms of the process. If we fail on that road, it may wrongfully
suggest that feature branches do not work.

There are two things that QoS subteam and broader Neutron community
should solve to make the merge happen.

1. for QoS subteam, complete the feature, get the code into good shape
that does not lower the quality bar set for master (meaning, it's
clean, it's idiomatic, it's covered by misc types of tests, it's
properly documented, etc.)

2. for QoS subteam, arrange everything needed to make review process
for merge-back *meaningful*.

3. for broad community, provide meaningful feedback for the feature
and accommodate merge-back if the feature branch is considered ready
for that.

QoS subteam believes that review process for merge-back should not be
shallow rubber stamping, so active participation from core reviewers
external to the subteam is highly desired. We appreciate any trust
someone may put into the subteam :), but we would still like others to
keep us honest. In the end, we are as interested in the overall
Neutron quality as other contributors. Of course, the feature will be
considered experimental for Liberty, but still we don't want to merge
anything completely wrong or something that would break others. :)
Here I will note that the subteam paid significant attention to
decouple the feature from other parts of Neutron, so there should be
few places where its integration in master could break other stuff.
That said... we'll see. ;)

To handle 1., I suggest QoS subteam follows the priority list:
- - complete PoC implementation (some agent side pieces are still not in
the tree);
- - cover the existing code with meaningful tests, if we see no or
limited coverage for any new code introduced;
- - close gaps that are currently marked as TODO(QoS) in the branch
(there are a lot of them);
- - after we consider it's done, do another walk thru each new piece of
code to see whether there is something we may clean up (typos,
comments, wording) to avoid (some of) nitpicking when we get to the
merge-back review process.

It's hard to expect that review for a thousands lines of code
merge-back patch can be meaningful and not loose reviewer attention.
So I suggest we take specific steps to avoid such outcome.

To accommodate 2. and 3., the following is proposed:
2.1 the feature is described in high to mid level details in devref,
with every separate piece of code being described: what it's for, how
it sticks into the whole picture, where the code is found, how it's
tested, etc.
2.2 the document is provided to broad community as part of the
merge-back review process. Reviewers are "(self-)assigned" to specific
pieces of the whole feature. The size of those pieces should be
consumable, small enough not to take risk of loosing too much review
attention while we go thru them. From QoS subteam side, people are
also assigned to those pieces to accommodate specific issues raised
during review in timely manner.
2.3 Once we get all the pieces ready for review (feature branch is
considered ready by the subteam; feature is described in devref and
split into logical separately reviewable parts; people from external
core reviewer team are on board with getting pieces to review; people
from QoS subteam are available for responses to feedback; ...), we may
want to dedicate a single day just to review the proposed feature. It
may be something like a virtual review sprint.

We may need another iteration of the latest entry point if feedback
requires significant time to handle. After one or more iterations of
feedback, assuming the branch gets to the point where everyone
involved in review process agrees that it's indeed ready for
merge-back, we finally accept it into master.

I think Miguel already signed up to provide some form of devref
description of the system till Wed. It will need attention from all
QoS subteam members to make sure it correctly reflects the desired
state of the tree, so keep an eye on his devref proposal.

Once in master, QoS subteam will polish the feature based on feedback
collected during review process and any bugs that are revealed after
the merge. For that, we should make sure that we have time in the
cycle to apply those late changes. It naturally goes into expected
schedule for the process.

It is desired that we complete the process till L-2 or the start of
L-3. Internally for QoS subteam, let's set end of L-2 as a goal to get
the branch ready for merge-back, and set start of L-3 as the expected
time when we reach external reviewers with merge-back proposal and go
thru their feedback. Hopefully, handling feedback won't take more than
a week, and we'll still have time to stabilize in master before code
freeze.

For reference, L-2 is end of July, so I kindly ask all people involved
in QoS subteam to be on top of the process and make everything
possible inside the branch to make it acceptable for master during
next several weeks.

Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVn6xuAAoJEC5aWaUY1u57KUoIAM/Nimn4zj6g3BRZ2899tgmh
THdNE93fbPqaIQAmdRBBhKHyaUHamJaji2szujhagpyie1QGpLzCyLt5pSsJX6Jf
G9F/bZ+8WjK59SkXCxrwKNsVlRkQmd/mUXmdGy8Z6Yb40+jknumeB0o/hollhpCN
EJkjCJLObOpVKlyrcRKdUggRxLwpHpiAbfxwh8b7AYSkFImLrbe7+X77nlt5Oi0u
DoscsHOtkPsM0XN5Tx+uBCPonxsoyCvBRVJ5n5sCBWF7d0xtCtm5gdyskXQglzSf
7LGZcYLWVEz8N5lHdNbhlzjV75IM5Hz0nPlccWzwQ6XnZKYN+/RQ5otIoGNl3aw=
=lCEX
-----END PGP SIGNATURE-----