Dear colleagues, Looks like we have consensus (lazy, but still consensus) on this topic: we don't need this role CL exposed to Fuel project. I have prepared a change [1] for our team structure policy.
My suggestion is to make Fuel is an aggregator of independent components. Component teams could have their formal or informal leads (i.e. component PTL) if needed but it is irrelevant to Fuel as a whole. As far as Fuel features usually require coordinated changes in multiple components, we need all Fuel specs to be reviewed by engineers from different backgrounds. "Avengers" approach (described above) has been rejected by Openstack Infra team, but we can use more traditional core group approach. I.e. Fuel-specs core team is responsible for reviewing and merging specs and in the proposed patch [1] it is explicitly written down that each spec must be approved by at least Puppet, UI, REST&Orchestration SMEs. It is also a responsibility of Fuel-specs core group to involve other SMEs if needed. [1] https://review.openstack.org/#/c/301194/ Vladimir Kozhukalov On Thu, Mar 31, 2016 at 6:47 PM, Serg Melikyan <[email protected]> wrote: > Hi fuelers, > > 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. > > 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. > > 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. > > 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. > > References: > [0] > https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html > > On Thu, Mar 31, 2016 at 3:22 AM, Evgeniy L <[email protected]> wrote: > >> Hi, >> >> 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. >> >> 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? >> >> 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. >> >> I would be really interested to see feedback from current component leads. >> >> Thanks, >> >> >> On Wed, Mar 30, 2016 at 2:20 PM, Vladimir Kozhukalov < >> [email protected]> wrote: >> >>> Dmitry, >>> >>> "No need to rush" does not mean we should postpone >>> team structure changes until Ocata. IMO, CL role >>> (when it is exposed to Fuel) contradicts to our >>> modularization activities. Fuel should be an aggregator >>> of components. What if we decide to use Ironic or >>> Neutron as Fuel components? Should we chose also >>> Ironic CL? NO! Ironic is an independent >>> project with its own PTL. >>> >>> I agree with Mike that we could remove this CL >>> role in a month if have consensus. But does it >>> make any sense to chose CLs now and then >>> immediately remove this role? Probably, it is better >>> to make a decision right now. I'd really like to >>> see here in this ML thread opinions of our current >>> CLs and other people. >>> >>> >>> >>> Vladimir Kozhukalov >>> >>> On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko < >>> [email protected]> wrote: >>> >>>> On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote: >>>> > > I think this call is too late to change a structure for now. I >>>> suggest >>>> > > that we always respect the policy we've accepted, and follow it. >>>> > > >>>> > > If Component Leads role is under a question, then I'd continue the >>>> > > discussion, hear opinion of current component leads, and give this >>>> a time >>>> > > to be discussed. I'd have nothing against removing this role in a >>>> month >>>> > > from now if we reach a consensus on this topic - no need to wait >>>> for the >>>> > > cycle end. >>>> > >>>> > Sure, there is no need to rush. I'd also like to see current CL >>>> opinions. >>>> >>>> Considering that, while there's an ongoing discussion on how to change >>>> Fuel team structure for Ocata, there's also an apparent consensus that >>>> we still want to have component leads for Newton, I'd like to call once >>>> again for volunteers to self-nominate for component leads of >>>> fuel-library, fuel-web, and fuel-ui. We've got 2 days left until >>>> nomination period is over, and no volunteer so far :( >>>> >>>> -- >>>> Dmitry Borodaenko >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >> >> > > > -- > Serg Melikyan, Development Manager at Mirantis, Inc. > http://mirantis.com | [email protected] > > __________________________________________________________________________ > 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
