<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 13, 2018 at 2:40 PM, Julia Kreger <span dir="ltr"><<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings fellow ironicans!<br>
<br>
As many of you might know an openstack/ironic-staging-<wbr>drivers[1]<br>
repository exists. What most might not know is that it was<br>
intentionally created outside of ironic's governance[2].<br>
<br>
At the time it was created ironic was moving towards removing drivers<br>
that did not meet our third-party CI requirement[3] to be in-tree. The<br>
repository was an attempt to give a home to what some might find<br>
useful or where third party CI is impractical or cost-prohibitive and<br>
thus could not be officially part of Ironic the service. There was<br>
hope that drivers could land in ironic-staging-drivers and possibly<br>
graduate to being moved in-tree with third-party CI. As our community<br>
has evolved we've not stopped and revisited the questions.<br></blockquote><div><br></div><div>Which questions? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With our most recent release over, I believe we need to ask ourselves<br>
if we should consider moving ironic-staging-drivers into our<br>
governance.<br>
<br>
Over the last couple of releases several contributors have found<br>
themselves trying to seek out two available reviewers to merge even<br>
trivial fixes[4]. Due to the team being so small this was no easy<br>
task. As a result, I'm wondering why not move the repository into<br>
governance, grant ironic-core review privileges upon the repository,<br>
and maintain the purpose and meaning of the repository. This would<br>
also result in the repository's release becoming managed via the<br>
release management process which is a plus.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We could then propose an actual graduation process and help alleviate<br>
some of the issues where driver code is iterated upon for long periods<br>
of time before landing. At the same time I can see at least one issue<br>
which is if we were to do that, then we would also need to manage<br>
removal through the same path.<br></blockquote><div><br></div><div>Is there any reason we can't have the same graduation process without bringing it into ironic's governance? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I know there are concerns over responsibility in terms of code<br>
ownership and quality, but I feel like we already hit such issues[5],<br>
like those encountered when Dmitry removed classic drivers[6] from the<br>
repository and also encountered issues just prior to the latest<br>
release[7][8].<br></blockquote><div><br></div><div>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).</div><div><br></div><div>Any code is going to have quality issues from time to time. The difference is who is responsible for taking care of those.</div><div><br></div><div>[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.</div><div><br></div><div>Besides, as Dmitry notes, he "has to" care about ironic-staging-drivers anyway, and 3 out of those 4 commits are his. :) </div><div><br></div><div>Overall I'm -1, but will live by whatever decision we come to.</div><div><br></div><div>// jim</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This topic has come up in passing at PTGs and most recently on IRC[9],<br>
and I think we ought to discuss it during our next weekly meeting[10].<br>
I've gone ahead and added an item to the agenda, but we can also<br>
discuss via email. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Julia<br>
<br>
[1]: <a href="http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n4571" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack-infra/project-<wbr>config/tree/gerrit/projects.<wbr>yaml#n4571</a><br>
[2]: <a href="http://git.openstack.org/cgit/openstack/ironic-staging-drivers/tree/README.rst#n16" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/ironic-staging-<wbr>drivers/tree/README.rst#n16</a><br>
[3]: <a href="https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-party-ci.html" rel="noreferrer" target="_blank">https://specs.openstack.org/<wbr>openstack/ironic-specs/specs/<wbr>approved/third-party-ci.html</a><br>
[4]: <a href="https://review.openstack.org/#/c/548943/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/548943/</a><br>
[5]: <a href="https://review.openstack.org/#/c/541916/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/541916/</a><br>
[6]: <a href="https://review.openstack.org/567902" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>567902</a><br>
[7]: <a href="https://review.openstack.org/590352" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>590352</a><br>
[8]: <a href="https://review.openstack.org/590401" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>590401</a><br>
[9]: <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/irclogs/%23openstack-<wbr>ironic/%23openstack-ironic.<wbr>2018-08-09.log.html#t2018-08-<wbr>09T11:55:27</a><br>
[10]: <a href="https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting" rel="noreferrer" target="_blank">https://wiki.openstack.org/<wbr>wiki/Meetings/Ironic#Agenda_<wbr>for_next_meeting</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div></div>