On 9 March 2016 at 08:16, Doug Hellmann <[email protected]> wrote:
> Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700: > > On 8 March 2016 at 15:07, Doug Hellmann <[email protected]> wrote: > > > > > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700: > > > > Hi folks, > > > > > > > > There's a feature or two that are pending to be delivered in Mitaka > > > [1,2], > > > > and those involve changes to both the server and client sides. > Ideally > > > we'd > > > > merge both sides in time for Mitaka RC and that implies that we > would be > > > > able to release a new version of the client including changes [3,4]. > This > > > > is especially important since a new client release would be > beneficial to > > > > improving test coverage as needed by [5]. > > > > > > > > Considering what we released already, and what the tip of master is > for > > > the > > > > client [6], I can't see any side effect that a new neutronclient > release > > > > may introduce. > > > > > > > > Having said that, I am leaning towards the all-or-none approach, but > the > > > > 'all' approach is predicated on the fact that we are indeed allowed > to > > > > release a new client and touch the global requirements. > > > > > > > > What's the release team's recommendation? Based on it, we may want to > > > > decide to defer these to as soon as N master opens up. > > > > > > I'm a bit reluctant to start touching the requirements lists for > > > feature work. We do have some bug fixes in the pipeline that will > > > require library releases, but those are for bugs not new features. > > > We also have one or two libs where feature work needed to be extended, > > > but none of those have dependencies outside of the project producing > > > them. > > > > > > The main reason to require a client release is for some *other* project > > > to take advantage of the new feature work. Is that planned? > > > > > > > Thanks for the prompt reply. Neutron would be the only consumer of these > > additions, and no other project has pending work to leverage these > > capabilities. > > In that case, I don't think we want to make an exception. Although > Neutron is the only user of this feature, I counted more than 50 other > projects that have python-neutronclient in a requirements file, and > that's a lot of potential for impact with a new release. > Yesterday I learned in the openstack-neutron channel that Heat has a change [1] that will need a newer version of the client. I agree that landing new features and release a new client version may be risky, and may also limit our chances to have a limited impact should we release a new version for a critical bug fix. [1] https://review.openstack.org/#/c/277567/ > > It seems like the options are to wait for Newton to land both parts of > the feature, or to land the server side during Mitaka and release a > feature update to the client as soon as Newton development opens. > I'd rather err on the side of caution, and give this more chance to bake in the master (Newton) trees. We are all too familiar with intermittent or impactful issues post-merge and we have enough critical/high fixes on our plate already. Thanks Doug! Cheers, Armando > > Doug > > > > > > > > > Doug > > > > > > > > > > > Many thanks, > > > > Armando > > > > > > > > [1] https://review.openstack.org/#/q/topic:bug/1468353 > > > > [2] https://review.openstack.org/#/q/topic:bug/1521783 > > > > [3] https://review.openstack.org/#/c/254280/ > > > > [4] https://review.openstack.org/#/c/288187/ > > > > [5] https://review.openstack.org/#/c/288392/ > > > > [6] > > > > > > > > https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a > > > > > > > __________________________________________________________________________ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > [email protected]?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
