<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Dear colleagues,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Looks like we have consensus (lazy, but still consensus) </div><div class="gmail_default" style="font-family:monospace,monospace">on this topic: we don't need this role CL exposed to Fuel </div><div class="gmail_default" style="font-family:monospace,monospace">project. I have prepared a change [1] for our team structure </div><div class="gmail_default" style="font-family:monospace,monospace">policy. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">My suggestion is to make Fuel is an aggregator</div><div class="gmail_default" style="font-family:monospace,monospace">of independent components. Component teams could have their </div><div class="gmail_default" style="font-family:monospace,monospace">formal or informal leads (i.e. component PTL) if needed </div><div class="gmail_default" style="font-family:monospace,monospace">but it is irrelevant to Fuel as a whole.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">As far as Fuel features usually require coordinated changes</div><div class="gmail_default" style="font-family:monospace,monospace">in multiple components, we need all Fuel specs to be reviewed</div><div class="gmail_default" style="font-family:monospace,monospace">by engineers from different backgrounds. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">"Avengers" approach (described above) has been rejected </div><div class="gmail_default" style="font-family:monospace,monospace">by Openstack Infra team, but we can use more traditional </div><div class="gmail_default" style="font-family:monospace,monospace">core group approach. I.e. Fuel-specs core team is responsible for </div><div class="gmail_default" style="font-family:monospace,monospace">reviewing and merging specs and in the proposed patch [1]</div><div class="gmail_default" style="font-family:monospace,monospace">it is explicitly written down that each spec must be </div><div class="gmail_default" style="font-family:monospace,monospace">approved by at least Puppet, UI, REST&Orchestration SMEs. </div><div class="gmail_default" style="font-family:monospace,monospace">It is also a responsibility of Fuel-specs core group </div><div class="gmail_default" style="font-family:monospace,monospace">to involve other SMEs if needed. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[1] <a href="https://review.openstack.org/#/c/301194/">https://review.openstack.org/#/c/301194/</a><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Thu, Mar 31, 2016 at 6:47 PM, Serg Melikyan <span dir="ltr"><<a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi fuelers,</div><div><br></div>only few hours left until period of self-nomination will be closed, but so far we don't have neither consensus regarding how to proceed further nor candidates. <div><br></div><div>I've increased period of self-nomination for another week (until April 7, 23:59 UTC) and expect to have decision about how we are going to proceed further if no one nominate himself or candidates for each of the three projects.</div><div><br></div><div>I propose to start with defining steps that we are going to take if no one nominate himself by April 7 and move forward with separate discussion regarding governance.</div><div><br></div><div>P.S. I strongly believe that declaring Component Leads role as obsolete require agreement among all members of Fuel team, which may take quite a lot of time. I think we should propose change-request to existing spec with governance [0], and have decision by end of Newton cycle. </div><div><br></div><div>References:</div><div>[0] <a href="https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html" target="_blank">https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html</a></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 3:22 AM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I'm not sure if it's a right place to continue this discussion, but if there are doubts that such role is needed, we should not wait for another half a year to drop it.</div><div><br></div><div>Also I'm not sure if a single engineer (or two engineers) can handle majority of upcoming patches + specs + meetings around features. Sergii and Igor put a lot of efforts to make it work, but does it really scale?</div><div><br></div><div>I think it would be better to offload more responsibilities to core groups, and if core team (of specific project) wants to see formal or informal leader, let them decide.</div><div><br></div><div>I would be really interested to see feedback from current component leads.</div><div><br></div><div>Thanks,</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 30, 2016 at 2:20 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Dmitry,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">"No need to rush" does not mean we should postpone </div><div class="gmail_default" style="font-family:monospace,monospace">team structure changes until Ocata. IMO, CL role </div><div class="gmail_default" style="font-family:monospace,monospace">(when it is exposed to Fuel) contradicts to our</div><div class="gmail_default" style="font-family:monospace,monospace">modularization activities. Fuel should be an aggregator</div><div class="gmail_default" style="font-family:monospace,monospace">of components. What if we decide to use Ironic or</div><div class="gmail_default" style="font-family:monospace,monospace">Neutron as Fuel components? Should we chose also</div><div class="gmail_default" style="font-family:monospace,monospace">Ironic CL? NO! Ironic is an independent</div><div class="gmail_default" style="font-family:monospace,monospace">project with its own PTL. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I agree with Mike that we could remove this CL </div><div class="gmail_default" style="font-family:monospace,monospace">role in a month if have consensus. But does it </div><div class="gmail_default" style="font-family:monospace,monospace">make any sense to chose CLs now and then </div><div class="gmail_default" style="font-family:monospace,monospace">immediately remove this role? Probably, it is better</div><div class="gmail_default" style="font-family:monospace,monospace">to make a decision right now. I'd really like to</div><div class="gmail_default" style="font-family:monospace,monospace">see here in this ML thread opinions of our current</div><div class="gmail_default" style="font-family:monospace,monospace">CLs and other people.</div><span><font color="#888888"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">  <br></div></font></span></div><div class="gmail_extra"><span><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div></font></span><div><div>
<br><div class="gmail_quote">On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:<br>
> > I think this call is too late to change a structure for now. I suggest<br>
> > that we always respect the policy we've accepted, and follow it.<br>
> ><br>
> > If Component Leads role is under a question, then I'd continue the<br>
> > discussion, hear opinion of current component leads, and give this a time<br>
> > to be discussed. I'd have nothing against removing this role in a month<br>
> > from now if we reach a consensus on this topic - no need to wait for the<br>
> > cycle end.<br>
><br>
> Sure, there is no need to rush. I'd also like to see current CL opinions.<br>
<br>
</span>Considering that, while there's an ongoing discussion on how to change<br>
Fuel team structure for Ocata, there's also an apparent consensus that<br>
we still want to have component leads for Newton, I'd like to call once<br>
again for volunteers to self-nominate for component leads of<br>
fuel-library, fuel-web, and fuel-ui. We've got 2 days left until<br>
nomination period is over, and no volunteer so far :(<br>
<span><font color="#888888"><br>
--<br>
Dmitry Borodaenko<br>
</font></span><div><div><br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Serg Melikyan, Development Manager at Mirantis, Inc.<br></div><div><a href="http://mirantis.com/" target="_blank">http://mirantis.com</a> | <a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a></div></div></div></div></div></div></div>
</span></div></div>
<br>__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>