Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0
2018年6月3日(日) 10:56 Chuck Short : > Hi > > On Sat, Jun 2, 2018 at 9:50 PM, Akihiro Motoki wrote: > >> Updates on Django 2.0 support. >> >> * 18 of 29 affected repositories now support Django 2.0 >> * 4 repositories have pending patches. >> * 3 repositories below need help from individual project teams as I don't >> have actual running environments of them. >>* heat-dashboard https://review.openstack.org/#/c/567591/ >>* murano-dashboard https://review.openstack.org/#/c/571950/ >>* watcher-dashboard >> * 4 repositories below needs more help as there seems no python3 support >> or projects looks inactive. >>monasca-ui, cloudkitty-dashboard, karbor-dashboard, >> group-based-policy-ui >> >> > Monasca-ui has python3 support however the CI hasn't been enabled. > Considering my bandwidth, it would be nice if monasca-ui team can work on django2.0 support. > > >> global-requirements and upper-constraints changes are also proposed. >> Considering good progress in general, I believe we can land requirements >> changes soon. >> >> https://review.openstack.org/#/q/topic:django-version+(status:open+OR+status:merged) >> >> Detail progress is found at >> https://etherpad.openstack.org/p/django20-support >> >> Thanks, >> Akihiro >> >> 2018年5月15日(火) 4:21 Ivan Kolodyazhny : >> >>> Hi all, >>> >>> From the Horizon's perspective, it would be good to support Django 1.11 >>> as long as we can since it's an LTS release [2]. >>> Django 2.0 support is also extremely important because of it's the first >>> step in a python3-only environment and step forward on supporting >>> next Django 2.2 LTS release which will be released next April. >>> >>> We have to be careful to not break existing plugins and deployments by >>> introducing new Django version requirement. >>> We need to work more closely with plugins teams to getting everything >>> ready for Django 2.0+ before we change our requirements.txt. >>> I don't want to introduce any breaking changes for current plugins so we >>> need to to be sure that each plugin supports Django 2.0. It means >>> plugins have to have voting Django 2.0 jobs on their gates at least. >>> I'll do my best on this effort and will work with plugins teams to do as >>> much as we can in Rocky timeframe. >>> >>> [2] https://www.djangoproject.com/download/ >>> >>> Regards, >>> Ivan Kolodyazhny, >>> http://blog.e0ne.info/ >>> >>> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki >>> wrote: >>> 2018年5月14日(月) 21:42 Doug Hellmann : > Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900: > > 2018年5月12日(土) 3:04 Doug Hellmann : > > > > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 > +0900: > > > > Hi zigo and horizon plugin maintainers, > > > > > > > > Horizon itself already supports Django 2.0 and horizon unit test > covers > > > > Django 2.0 with Python 3.5. > > > > > > > > A question to all is whether we change the upper bound of Django > from > > > <2.0 > > > > to <2.1. > > > > My proposal is to bump the upper bound of Django to <2.1 in > Rocky-2. > > > > (Note that Django 1.11 will continue to be used for python 2.7 > > > environment.) > > > > > > Do we need to cap it at all? We've been trying to express our > > > dependencies without caps and rely on the constraints list to > > > test using a common version because this offers the most > flexibility as > > > we move to newer versions over time. > > > > > > > The main reason we cap django version so far is that django minor > version > > releases > > contain some backward incompatible changes and also drop deprecated > > features. > > A new django minor version release like 1.11 usually breaks horizon > and > > plugins > > as horizon developers are not always checking django deprecations. > > OK. Having the cap in place makes it more complicated to test > upgrading, and then upgrade. Because we no longer synchronize > requirements, changing openstack/requirements does not trigger the > bot to propose the same change to all of the projects using the > dependency. Someone will have to do that by hand in the future, as we > are doing with eventlet right now > (https://review.openstack.org/#/q/topic:uncap-eventlet). > > Without the cap, we can test the upgrade by proposing a constraint > update and running the horizon (and/or plugin) unit tests. When those > tests pass, we can then step forward all at once by approving the > constraint change. > Thanks for the detail context. Honestly I am not sure which is better to cap or uncap the django version. We can try uncapping now and see what happens in the community. cross-horizon-(py27|py35) jobs of openstack/requirements checks if horizon works with a new version. it works for horizon, but perhaps it
Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0
Hi On Sat, Jun 2, 2018 at 9:50 PM, Akihiro Motoki wrote: > Updates on Django 2.0 support. > > * 18 of 29 affected repositories now support Django 2.0 > * 4 repositories have pending patches. > * 3 repositories below need help from individual project teams as I don't > have actual running environments of them. >* heat-dashboard https://review.openstack.org/#/c/567591/ >* murano-dashboard https://review.openstack.org/#/c/571950/ >* watcher-dashboard > * 4 repositories below needs more help as there seems no python3 support > or projects looks inactive. >monasca-ui, cloudkitty-dashboard, karbor-dashboard, > group-based-policy-ui > > Monasca-ui has python3 support however the CI hasn't been enabled. > global-requirements and upper-constraints changes are also proposed. > Considering good progress in general, I believe we can land requirements > changes soon. > https://review.openstack.org/#/q/topic:django-version+( > status:open+OR+status:merged) > > Detail progress is found at https://etherpad.openstack. > org/p/django20-support > > Thanks, > Akihiro > > 2018年5月15日(火) 4:21 Ivan Kolodyazhny : > >> Hi all, >> >> From the Horizon's perspective, it would be good to support Django 1.11 >> as long as we can since it's an LTS release [2]. >> Django 2.0 support is also extremely important because of it's the first >> step in a python3-only environment and step forward on supporting >> next Django 2.2 LTS release which will be released next April. >> >> We have to be careful to not break existing plugins and deployments by >> introducing new Django version requirement. >> We need to work more closely with plugins teams to getting everything >> ready for Django 2.0+ before we change our requirements.txt. >> I don't want to introduce any breaking changes for current plugins so we >> need to to be sure that each plugin supports Django 2.0. It means >> plugins have to have voting Django 2.0 jobs on their gates at least. I'll >> do my best on this effort and will work with plugins teams to do as >> much as we can in Rocky timeframe. >> >> [2] https://www.djangoproject.com/download/ >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> >> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki >> wrote: >> >>> >>> >>> 2018年5月14日(月) 21:42 Doug Hellmann : >>> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900: > 2018年5月12日(土) 3:04 Doug Hellmann : > > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900: > > > Hi zigo and horizon plugin maintainers, > > > > > > Horizon itself already supports Django 2.0 and horizon unit test covers > > > Django 2.0 with Python 3.5. > > > > > > A question to all is whether we change the upper bound of Django from > > <2.0 > > > to <2.1. > > > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2. > > > (Note that Django 1.11 will continue to be used for python 2.7 > > environment.) > > > > Do we need to cap it at all? We've been trying to express our > > dependencies without caps and rely on the constraints list to > > test using a common version because this offers the most flexibility as > > we move to newer versions over time. > > > > The main reason we cap django version so far is that django minor version > releases > contain some backward incompatible changes and also drop deprecated > features. > A new django minor version release like 1.11 usually breaks horizon and > plugins > as horizon developers are not always checking django deprecations. OK. Having the cap in place makes it more complicated to test upgrading, and then upgrade. Because we no longer synchronize requirements, changing openstack/requirements does not trigger the bot to propose the same change to all of the projects using the dependency. Someone will have to do that by hand in the future, as we are doing with eventlet right now (https://review.openstack.org/#/q/topic:uncap-eventlet). Without the cap, we can test the upgrade by proposing a constraint update and running the horizon (and/or plugin) unit tests. When those tests pass, we can then step forward all at once by approving the constraint change. >>> >>> Thanks for the detail context. >>> >>> Honestly I am not sure which is better to cap or uncap the django >>> version. >>> We can try uncapping now and see what happens in the community. >>> >>> cross-horizon-(py27|py35) jobs of openstack/requirements checks >>> if horizon works with a new version. it works for horizon, but perhaps >>> it potentially >>> break horizon plugins as it takes time to catch up with such changes. >>> On the other hand, a version bump in upper-constraints.txt would be >>> a good trigger for horizon plugin maintainers to sync all requirements. >>> >>> In addition, requirements
Re: [openstack-dev] [horizon] Scheduling switch to django >= 2.0
Updates on Django 2.0 support. * 18 of 29 affected repositories now support Django 2.0 * 4 repositories have pending patches. * 3 repositories below need help from individual project teams as I don't have actual running environments of them. * heat-dashboard https://review.openstack.org/#/c/567591/ * murano-dashboard https://review.openstack.org/#/c/571950/ * watcher-dashboard * 4 repositories below needs more help as there seems no python3 support or projects looks inactive. monasca-ui, cloudkitty-dashboard, karbor-dashboard, group-based-policy-ui global-requirements and upper-constraints changes are also proposed. Considering good progress in general, I believe we can land requirements changes soon. https://review.openstack.org/#/q/topic:django-version+(status:open+OR+status:merged) Detail progress is found at https://etherpad.openstack.org/p/django20-support Thanks, Akihiro 2018年5月15日(火) 4:21 Ivan Kolodyazhny : > Hi all, > > From the Horizon's perspective, it would be good to support Django 1.11 as > long as we can since it's an LTS release [2]. > Django 2.0 support is also extremely important because of it's the first > step in a python3-only environment and step forward on supporting > next Django 2.2 LTS release which will be released next April. > > We have to be careful to not break existing plugins and deployments by > introducing new Django version requirement. > We need to work more closely with plugins teams to getting everything > ready for Django 2.0+ before we change our requirements.txt. > I don't want to introduce any breaking changes for current plugins so we > need to to be sure that each plugin supports Django 2.0. It means > plugins have to have voting Django 2.0 jobs on their gates at least. I'll > do my best on this effort and will work with plugins teams to do as > much as we can in Rocky timeframe. > > [2] https://www.djangoproject.com/download/ > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki wrote: > >> >> >> 2018年5月14日(月) 21:42 Doug Hellmann : >> >>> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900: >>> > 2018年5月12日(土) 3:04 Doug Hellmann : >>> > >>> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900: >>> > > > Hi zigo and horizon plugin maintainers, >>> > > > >>> > > > Horizon itself already supports Django 2.0 and horizon unit test >>> covers >>> > > > Django 2.0 with Python 3.5. >>> > > > >>> > > > A question to all is whether we change the upper bound of Django >>> from >>> > > <2.0 >>> > > > to <2.1. >>> > > > My proposal is to bump the upper bound of Django to <2.1 in >>> Rocky-2. >>> > > > (Note that Django 1.11 will continue to be used for python 2.7 >>> > > environment.) >>> > > >>> > > Do we need to cap it at all? We've been trying to express our >>> > > dependencies without caps and rely on the constraints list to >>> > > test using a common version because this offers the most flexibility >>> as >>> > > we move to newer versions over time. >>> > > >>> > >>> > The main reason we cap django version so far is that django minor >>> version >>> > releases >>> > contain some backward incompatible changes and also drop deprecated >>> > features. >>> > A new django minor version release like 1.11 usually breaks horizon and >>> > plugins >>> > as horizon developers are not always checking django deprecations. >>> >>> OK. Having the cap in place makes it more complicated to test >>> upgrading, and then upgrade. Because we no longer synchronize >>> requirements, changing openstack/requirements does not trigger the >>> bot to propose the same change to all of the projects using the >>> dependency. Someone will have to do that by hand in the future, as we >>> are doing with eventlet right now >>> (https://review.openstack.org/#/q/topic:uncap-eventlet). >>> >>> Without the cap, we can test the upgrade by proposing a constraint >>> update and running the horizon (and/or plugin) unit tests. When those >>> tests pass, we can then step forward all at once by approving the >>> constraint change. >>> >> >> Thanks for the detail context. >> >> Honestly I am not sure which is better to cap or uncap the django version. >> We can try uncapping now and see what happens in the community. >> >> cross-horizon-(py27|py35) jobs of openstack/requirements checks >> if horizon works with a new version. it works for horizon, but perhaps it >> potentially >> break horizon plugins as it takes time to catch up with such changes. >> On the other hand, a version bump in upper-constraints.txt would be >> a good trigger for horizon plugin maintainers to sync all requirements. >> >> In addition, requirements are not synchronized automatically, >> so it seems not feasible to propose requirements changes per django >> version change. >> >> >>> >>> > >>> > I have a question on uncapping the django version. >>> > How can users/operators know which versions are supported? >>> > Do they need to
[openstack-dev] [cinder] Removing Support for Drivers with Failing CI's ...
All, This note is to make everyone aware that I have submitted patches for a number of drivers that have not run 3rd party CI in 60 or more days. The following is a list of the drivers, how long since their CI last ran and links to the patches which mark them as unsupported drivers: * DataCore CI – 99 Days - https://review.openstack.org/571533 * Dell EMC CorpHD CI – 121 Days - https://review.openstack.org/571555 * HGST Solutions CI – 306 Days - https://review.openstack.org/571560 * IBM GPFS CI – 212 Days - https://review.openstack.org/571590 * Itri Disco CI – 110 Days - https://review.openstack.org/571592 * Nimble Storage CI – 78 Days - https://review.openstack.org/571599 * StorPool – Unknown - https://review.openstack.org/571935 * Vedams –HPMSA – 442 Days - https://review.openstack.org/571940 * Brocade OpenStack – CI – 261 Days - https://review.openstack.org/571943 All of these drivers will be marked unsupported for the Rocky release and will be removed in the Stein release if the 3rd Party CI is not returned to a working state. If your driver is on the list and you have questions please respond to this thread and we can discuss what needs to be done to return support for your driver. Thank you for your attention to this matter! Jay (jungleboy) __ 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
Re: [openstack-dev] [tc] Organizational diversity tag
> -Original Message- > From: Doug Hellmann > Sent: Saturday, June 2, 2018 4:26 PM > To: openstack-dev > Subject: Re: [openstack-dev] [tc] Organizational diversity tag > > Excerpts from amrith.kumar's message of 2018-06-02 15:06:27 -0400: > > Every project on the one-way-trip to inactivity starts with what some > > people will wishfully call a 'transient period' of reduced activity. > > Once the transient nature is no longer the case (either it becomes > > active or the transient becomes permanent) the normal process of > > eviction can begin. As the guy who came up with the maintenance-mode > > tag, so as to apply it to Trove, I believe that both the diversity tag > > and the maintenance mode tag have a good reason to exist, and should > > both be retained independent of each other. > > > > The logic always was, and should remain, that diversity is a measure > > of wide multi-organizational support for a project; not measured in > > the total volume of commits but the fraction of commits. There was > > much discussion about the knobs in the diversity tag measurement when > > Flavio made the changes some years back. I'm sorry I didn't attend the > > session in Vancouver but I'll try and tune in to a TC office hours > > session and maybe get a rundown of what precipitated this decision to > move away from the diversity tag. > > We're talking about how to improve reporting on diversity, not stop doing it. Why not just automate the thing that we have right now and have something kick a review automatically if the diversity in a team changes (per current formula)? > > Doug > > __ > > 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 __ 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
Re: [openstack-dev] [tc] Organizational diversity tag
Excerpts from amrith.kumar's message of 2018-06-02 15:06:27 -0400: > Every project on the one-way-trip to inactivity starts with what some people > will wishfully call a 'transient period' of reduced activity. Once the > transient nature is no longer the case (either it becomes active or the > transient becomes permanent) the normal process of eviction can begin. As > the guy who came up with the maintenance-mode tag, so as to apply it to > Trove, I believe that both the diversity tag and the maintenance mode tag > have a good reason to exist, and should both be retained independent of each > other. > > The logic always was, and should remain, that diversity is a measure of wide > multi-organizational support for a project; not measured in the total volume > of commits but the fraction of commits. There was much discussion about the > knobs in the diversity tag measurement when Flavio made the changes some > years back. I'm sorry I didn't attend the session in Vancouver but I'll try > and tune in to a TC office hours session and maybe get a rundown of what > precipitated this decision to move away from the diversity tag. We're talking about how to improve reporting on diversity, not stop doing it. Doug __ 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
Re: [openstack-dev] [tc] Organizational diversity tag
Excerpts from Jeremy Stanley's message of 2018-06-02 18:51:47 +: > On 2018-06-02 13:23:24 -0400 (-0400), Doug Hellmann wrote: > [...] > > It feels like we would be saying that we don't trust 2 core reviewers > > from the same company to put the project's goals or priorities over > > their employer's. And that doesn't feel like an assumption I would > > want us to encourage through a tag meant to show the health of the > > project. > [...] > > That's one way of putting it. On the other hand, if we ostensibly > have that sort of guideline (say, two core reviewers shouldn't be > the only ones to review a change submitted by someone else from > their same organization if the team is large and diverse enough to > support such a pattern) then it gives our reviewers a better > argument to push back on their management _if_ they're being > strongly urged to review/approve certain patches. At least then they > can say, "this really isn't going to fly because we have to get a > reviewer from another organization to agree it's in the best > interests of the project" rather than "fire me if you want but I'm > not approving that change, no matter how much your product launch is > going to be delayed." Do we have that problem? I honestly don't know how much pressure other folks are feeling. My impression is that we've mostly become good at finding the necessary compromises, but my experience doesn't cover all of our teams. > > While I'd like to think a lot of us have the ability to push back on > those sorts of adverse influences directly, I have a feeling not > everyone can comfortably do so. On the other hand, it might also > just be easy enough to give one of your fellow reviewers in another > org a heads up that maybe they should take a look at that patch over > there and provide some quick feedback... __ 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
Re: [openstack-dev] [tc] Organizational diversity tag
> -Original Message- > From: Zane Bitter > Sent: Friday, June 1, 2018 10:11 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [tc] Organizational diversity tag > > On 26/05/18 17:46, Mohammed Naser wrote: > > Hi everyone! > > > > During the TC retrospective at the OpenStack summit last week, the > > topic of the organizational diversity tag is becoming irrelevant was > > brought up by Thierry (ttx)[1]. It seems that for projects that are > > not very active, they can easily lose this tag with a few changes by > > perhaps the infrastructure team for CI related fixes. > > > > As an action item, Thierry and I have paired up in order to look into > > a way to resolve this issue. There have been ideas to switch this to > > a report that is published at the end of the cycle rather than > > continuously. Julia (TheJulia) suggested that we change or track > > different types of diversity. > > > > Before we start diving into solutions, I wanted to bring this topic up > > to the mailing list and ask for any suggestions. In digging the > > codebase behind this[2], I've found that there are some knobs that we > > can also tweak if need-be, or perhaps we can adjust those numbers > > depending on the number of commits. > > Crazy idea: what if we dropped the idea of measuring the diversity and > allowed teams to decide when they applied the tag to themselves like we do > for other tags. (No wait! Come back!) > > Some teams enforce a requirement that the 2 core +2s come from reviewers > with different affiliations. We would say that any project that enforces that > rule would get the diversity tag. Then it's actually attached to something > concrete, and teams could decide for themselves when to drop it (because > they would start having difficulty merging stuff otherwise). > [Amrith Kumar] Isn't that what the current formula would flag as being a diverse project > I'm not entirely sold on this, but it's an idea I had that I wanted to throw > out > there :) > > cheers, > Zane. > > __ > > 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 __ 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
Re: [openstack-dev] [tc] Organizational diversity tag
Every project on the one-way-trip to inactivity starts with what some people will wishfully call a 'transient period' of reduced activity. Once the transient nature is no longer the case (either it becomes active or the transient becomes permanent) the normal process of eviction can begin. As the guy who came up with the maintenance-mode tag, so as to apply it to Trove, I believe that both the diversity tag and the maintenance mode tag have a good reason to exist, and should both be retained independent of each other. The logic always was, and should remain, that diversity is a measure of wide multi-organizational support for a project; not measured in the total volume of commits but the fraction of commits. There was much discussion about the knobs in the diversity tag measurement when Flavio made the changes some years back. I'm sorry I didn't attend the session in Vancouver but I'll try and tune in to a TC office hours session and maybe get a rundown of what precipitated this decision to move away from the diversity tag. -amrith > -Original Message- > From: Jeremy Stanley > Sent: Tuesday, May 29, 2018 5:43 PM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [tc] Organizational diversity tag > > On 2018-05-29 13:17:50 -0400 (-0400), Doug Hellmann wrote: > [...] > > We have the status:maintenance-mode tag[3] today. How would a new > > "low-activity" tag be differentiated from the existing one? > [...] > > status:maintenance-mode is (as it says on the tin) a subjective indicator that > a team has entered a transient period of reduced activity. By contrast, a low- > activity tag (maybe it should be something more innocuous like low-churn?) > would be an objective indicator that attempts to make contributor diversity > assertions are doomed to fail the statistical significance test. We could > consider overloading status:maintenance-mode for this purpose, but some > teams perhaps simply don't have large amounts of code change ever and > that's just a normal effect of how they operate. > -- > Jeremy Stanley __ 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
Re: [openstack-dev] [tc] Organizational diversity tag
On 2018-06-02 13:23:24 -0400 (-0400), Doug Hellmann wrote: [...] > It feels like we would be saying that we don't trust 2 core reviewers > from the same company to put the project's goals or priorities over > their employer's. And that doesn't feel like an assumption I would > want us to encourage through a tag meant to show the health of the > project. [...] That's one way of putting it. On the other hand, if we ostensibly have that sort of guideline (say, two core reviewers shouldn't be the only ones to review a change submitted by someone else from their same organization if the team is large and diverse enough to support such a pattern) then it gives our reviewers a better argument to push back on their management _if_ they're being strongly urged to review/approve certain patches. At least then they can say, "this really isn't going to fly because we have to get a reviewer from another organization to agree it's in the best interests of the project" rather than "fire me if you want but I'm not approving that change, no matter how much your product launch is going to be delayed." While I'd like to think a lot of us have the ability to push back on those sorts of adverse influences directly, I have a feeling not everyone can comfortably do so. On the other hand, it might also just be easy enough to give one of your fellow reviewers in another org a heads up that maybe they should take a look at that patch over there and provide some quick feedback... -- Jeremy Stanley signature.asc Description: 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
Re: [openstack-dev] [tc] Organizational diversity tag
On 06/02/2018 12:23 PM, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: On 01/06/18 12:18, Doug Hellmann wrote: [snip] Is that rule a sign of a healthy team dynamic, that we would want to spread to the whole community? Yeah, this part I am pretty unsure about too. For some projects it probably is. For others it may just be an unnecessary obstacle, although I don't think it'd actually be *un*healthy for any project, assuming a big enough and diverse enough team (which should be a goal for the whole community). It feels like we would be saying that we don't trust 2 core reviewers from the same company to put the project's goals or priorities over their employer's. And that doesn't feel like an assumption I would want us to encourage through a tag meant to show the health of the project. I have to agree. In general, I have tried to at least give the opportunity for other cores from other companies to review patches before approving, but there have been times where I have approved patches in Cinder where the only other +2 was someone from the same company. I don't see anything wrong with this in most cases. As an exceptional example, I'm actually happy to see two +2's from Red Hat cores on Ceph related patches. I think it's a good thing to encourage a mix, but I have never considered it a hard and fast rule. Maybe I'm reading too much into it? Or it is more of a problem than I have experienced? Doug __ 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 __ 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
[openstack-dev] [Zun][Octavia] OpenStack Zun as Octavia driver
Hi all, We are planning a feature about Zun integration in Octavia [1]. At highest level, the idea is to have Zun to provide docker containers for Octavia to host their software-based load balancing backend. An immediate benefit is to speed up the Octavia's gate so that they can run more test cases for a better coverage. Zun will be beneficial for collecting potential valuable feedback through this practical use case. If anyone interest in this work, please leave a note at the storyboard [1]. I believe the assignee will receive a good support from both Zun and Octavia team and the work will be greatly rewarded. [1] https://storyboard.openstack.org/#!/story/2002117 Best regards, Hongbin __ 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
Re: [openstack-dev] [tc] Organizational diversity tag
Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: > On 01/06/18 12:18, Doug Hellmann wrote: [snip] > > Is that rule a sign of a healthy team dynamic, that we would want > > to spread to the whole community? > > Yeah, this part I am pretty unsure about too. For some projects it > probably is. For others it may just be an unnecessary obstacle, although > I don't think it'd actually be *un*healthy for any project, assuming a > big enough and diverse enough team (which should be a goal for the whole > community). It feels like we would be saying that we don't trust 2 core reviewers from the same company to put the project's goals or priorities over their employer's. And that doesn't feel like an assumption I would want us to encourage through a tag meant to show the health of the project. Maybe I'm reading too much into it? Or it is more of a problem than I have experienced? Doug __ 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
Re: [openstack-dev] Winterscale: a proposal regarding the project infrastructure
On Fri, Jun 1, 2018 at 7:23 AM, James E. Blair wrote: > Joshua Hesketh writes: > > > So the "winterscale infrastructure council"'s purview is quite limited in > > scope to just govern the services provided? > > > > If so, would you foresee a need to maintain some kind of "Infrastructure > > council" as it exists at the moment to be the technical design body? > > For the foreseeable future, I think the "winterscale infrastructure > team" can probably handle that. If it starts to sprawl again, we can > make a new body. > > > Specifically, wouldn't we still want somewhere for the "winterscale > > infrastructure team" to be represented and would that expand to any > > infrastructure-related core teams? > > Can you elaborate on this? I'm not following. > I think your first response answers this a little bit. That is, the "winterscale infrastructure team" serves the purpose of technical design (that is currently done by the "Infrastructure Council", so we've got some change in terminology that will be initially confusing). Currently though the "Infrastructure Council" includes "All members of any infrastructure project core team" which would include people from say git-review core. My question was how do we still include infrastructure-related core members (such as git-review-core) in the new world order? Hope that makes more sense. Cheers, Josh > > -Jim > > __ > 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 > __ 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
