Re: [openstack-dev] [ironic] ironic-staging-drivers: what to do?
Hi, On Mon, Aug 13, 2018 at 2:40 PM, Julia Kreger wrote: > Greetings fellow ironicans! > > As many of you might know an openstack/ironic-staging-drivers[1] > repository exists. What most might not know is that it was > intentionally created outside of ironic's governance[2]. > ... > > This topic has come up in passing at PTGs and most recently on IRC[9], > and I think we ought to discuss it during our next weekly meeting[10]. > I've gone ahead and added an item to the agenda, but we can also > discuss via email. > > We had a short discussion on this in our meeting today [1]. To summarize, we did not discuss whether to put it under the ironic governance. We did agree that it would be ok to have the ironic cores be cores in ironic-staging-drivers. There would be no guarantee (of course) that the ironic cores would actually review any of these. Julia will get in touch with the cores in ironic-staging-drivers, to see if they would like to add ironic-cores as cores. --ruby [1] http://eavesdrop.openstack.org/meetings/ironic/2018/ironic.2018-08-20-15.00.log.html#l-118 __ 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] [ironic] ironic-staging-drivers: what to do?
Hi Julia, Thanks for bringing this up. On Mon, Aug 13, 2018, 2:41 PM Julia Kreger, wrote: > Greetings fellow ironicans! > > As many of you might know an openstack/ironic-staging-drivers[1] > repository exists. What most might not know is that it was > intentionally created outside of ironic's governance[2]. > > At the time it was created ironic was moving towards removing drivers > that did not meet our third-party CI requirement[3] to be in-tree. The > repository was an attempt to give a home to what some might find > useful or where third party CI is impractical or cost-prohibitive and > thus could not be officially part of Ironic the service. There was > hope that drivers could land in ironic-staging-drivers and possibly > graduate to being moved in-tree with third-party CI. As our community > has evolved we've not stopped and revisited the questions. > > With our most recent release over, I believe we need to ask ourselves > if we should consider moving ironic-staging-drivers into our > governance. > > Over the last couple of releases several contributors have found > themselves trying to seek out two available reviewers to merge even > trivial fixes[4]. Due to the team being so small this was no easy > task. As a result, I'm wondering why not move the repository into > governance, grant ironic-core review privileges upon the repository, > and maintain the purpose and meaning of the repository. This would > also result in the repository's release becoming managed via the > release management process which is a plus. > If I understand, it seems like the main issue is lack of reviewers. As mentioned by others, I would not be opposed to adding existing ironic cores to this repo. Whether folks review is a different question. We could then propose an actual graduation process and help alleviate > some of the issues where driver code is iterated upon for long periods > of time before landing. At the same time I can see at least one issue > which is if we were to do that, then we would also need to manage > removal through the same path. > I am not sure I see any advantages to this. The ansible driver was in the staging repo for awhile before it went into ironic so we know that is do-able :) > I know there are concerns over responsibility in terms of code > ownership and quality, but I feel like we already hit such issues[5], > like those encountered when Dmitry removed classic drivers[6] from the > repository and also encountered issues just prior to the latest > release[7][8]. > I don't mind making changes or reviewing changes to this repo, especially if there are unit tests. However, that is the most responsibility I am comfortable having with this repo. Right now, I don't see any good reasons for putting it under the ironic governance. I am, of course, open to being convinced otherwise! --ruby > This topic has come up in passing at PTGs and most recently on IRC[9], > and I think we ought to discuss it during our next weekly meeting[10]. > I've gone ahead and added an item to the agenda, but we can also > discuss via email. > -Julia > > [1]: > http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n4571 > [2]: > http://git.openstack.org/cgit/openstack/ironic-staging-drivers/tree/README.rst#n16 > [3]: > https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-party-ci.html > [4]: https://review.openstack.org/#/c/548943/ > [5]: https://review.openstack.org/#/c/541916/ > [6]: https://review.openstack.org/567902 > [7]: https://review.openstack.org/590352 > [8]: https://review.openstack.org/590401 > [9]: > http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27 > [10]: > https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting > > __ > 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] [ironic] ironic-staging-drivers: what to do?
On Mon, Aug 13, 2018 at 2:40 PM, Julia Kreger wrote: > Greetings fellow ironicans! > > As many of you might know an openstack/ironic-staging-drivers[1] > repository exists. What most might not know is that it was > intentionally created outside of ironic's governance[2]. > > At the time it was created ironic was moving towards removing drivers > that did not meet our third-party CI requirement[3] to be in-tree. The > repository was an attempt to give a home to what some might find > useful or where third party CI is impractical or cost-prohibitive and > thus could not be officially part of Ironic the service. There was > hope that drivers could land in ironic-staging-drivers and possibly > graduate to being moved in-tree with third-party CI. As our community > has evolved we've not stopped and revisited the questions. > Which questions? With our most recent release over, I believe we need to ask ourselves > if we should consider moving ironic-staging-drivers into our > governance. > > Over the last couple of releases several contributors have found > themselves trying to seek out two available reviewers to merge even > trivial fixes[4]. Due to the team being so small this was no easy > task. As a result, I'm wondering why not move the repository into > governance, grant ironic-core review privileges upon the repository, > and maintain the purpose and meaning of the repository. This would > also result in the repository's release becoming managed via the > release management process which is a plus. > Agree with Dmitry, just because ironic-core has +2 doesn't mean they will look at it. I'm not opposed to adding more of the ironic-core folks to it outside of governance, though. While I probably wouldn't review ironic-staging-drivers often whether it is in our governance or not, I'd be happy to review trivial changes to help move things along. We could then propose an actual graduation process and help alleviate > some of the issues where driver code is iterated upon for long periods > of time before landing. At the same time I can see at least one issue > which is if we were to do that, then we would also need to manage > removal through the same path. > Is there any reason we can't have the same graduation process without bringing it into ironic's governance? I know there are concerns over responsibility in terms of code > ownership and quality, but I feel like we already hit such issues[5], > like those encountered when Dmitry removed classic drivers[6] from the > repository and also encountered issues just prior to the latest > release[7][8]. > Yes, this is my primary concern. I don't believe that the ironic team should be responsible for this code, when we can't validate it (manually or via CI). Any code is going to have quality issues from time to time. The difference is who is responsible for taking care of those. [5] and [6] are examples of where we knew we were going to break out-of-tree drivers, and helped fix them because we're kind people - not where we were taking ownership of the code. I suspect if we were aware of other out-of-tree drivers we would have been happy to fix those as well. [7] and [8] are just general code maintenance, and aren't really an argument to me for having the ironic team take over this project. Besides, as Dmitry notes, he "has to" care about ironic-staging-drivers anyway, and 3 out of those 4 commits are his. :) Overall I'm -1, but will live by whatever decision we come to. // jim This topic has come up in passing at PTGs and most recently on IRC[9], > and I think we ought to discuss it during our next weekly meeting[10]. > I've gone ahead and added an item to the agenda, but we can also > discuss via email. > -Julia > > [1]: http://git.openstack.org/cgit/openstack-infra/project- > config/tree/gerrit/projects.yaml#n4571 > [2]: http://git.openstack.org/cgit/openstack/ironic-staging- > drivers/tree/README.rst#n16 > [3]: https://specs.openstack.org/openstack/ironic-specs/specs/ > approved/third-party-ci.html > [4]: https://review.openstack.org/#/c/548943/ > [5]: https://review.openstack.org/#/c/541916/ > [6]: https://review.openstack.org/567902 > [7]: https://review.openstack.org/590352 > [8]: https://review.openstack.org/590401 > [9]: http://eavesdrop.openstack.org/irclogs/%23openstack- > ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27 > [10]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_ > for_next_meeting > > __ > 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
Re: [openstack-dev] [ironic] ironic-staging-drivers: what to do?
Inline On 08/13/2018 08:40 PM, Julia Kreger wrote: Greetings fellow ironicans! As many of you might know an openstack/ironic-staging-drivers[1] repository exists. What most might not know is that it was intentionally created outside of ironic's governance[2]. At the time it was created ironic was moving towards removing drivers that did not meet our third-party CI requirement[3] to be in-tree. The repository was an attempt to give a home to what some might find useful or where third party CI is impractical or cost-prohibitive and thus could not be officially part of Ironic the service. There was hope that drivers could land in ironic-staging-drivers and possibly graduate to being moved in-tree with third-party CI. As our community has evolved we've not stopped and revisited the questions. With our most recent release over, I believe we need to ask ourselves if we should consider moving ironic-staging-drivers into our governance. Not voting on this, since I'm obviously biased. Consider me +0 :) Over the last couple of releases several contributors have found themselves trying to seek out two available reviewers to merge even trivial fixes[4]. Due to the team being so small this was no easy task. As a result, I'm wondering why not move the repository into governance, grant ironic-core review privileges upon the repository, and maintain the purpose and meaning of the repository. This would also result in the repository's release becoming managed via the release management process which is a plus. Strictly speaking, nothing prevents us from granting ironic-core +2 on it right now. It's a different question whether they'll actually review it. We need a commitment from >50% cores to review it more or less regularly, otherwise we'll end up in the same situation. We could then propose an actual graduation process and help alleviate some of the issues where driver code is iterated upon for long periods of time before landing. At the same time I can see at least one issue which is if we were to do that, then we would also need to manage removal through the same path. I don't think we really "need to", but we certainly can. Now that I think that we could use ironic-staging-drivers as an *actual* staging area for new drivers, I'm starting to lean towards +1 on this whole idea. This still leaves some drivers that will never get a CI. I know there are concerns over responsibility in terms of code ownership and quality, but I feel like we already hit such issues[5], like those encountered when Dmitry removed classic drivers[6] from the repository and also encountered issues just prior to the latest release[7][8]. Well, yes, I personally have to care about this repository anyway. Dmitry This topic has come up in passing at PTGs and most recently on IRC[9], and I think we ought to discuss it during our next weekly meeting[10]. I've gone ahead and added an item to the agenda, but we can also discuss via email. -Julia [1]: http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n4571 [2]: http://git.openstack.org/cgit/openstack/ironic-staging-drivers/tree/README.rst#n16 [3]: https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-party-ci.html [4]: https://review.openstack.org/#/c/548943/ [5]: https://review.openstack.org/#/c/541916/ [6]: https://review.openstack.org/567902 [7]: https://review.openstack.org/590352 [8]: https://review.openstack.org/590401 [9]: http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27 [10]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting __ 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
