-----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----- __________________________________________________________________________ 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