Bogdan, Team, So i got this etherpad started. Please add policy ideas at the top and volunteer for the team too.,
https://etherpad.openstack.org/p/LTS-proposal Thanks, Dims On Wed, Nov 15, 2017 at 3:08 AM, Bogdan Dobrelya <bdobr...@redhat.com> wrote: >>> The concept, in general, is to create a new set of cores from these >>> groups, and use 3rd party CI to validate patches. There are lots of >>> details to be worked out yet, but our amazing UC (User Committee) will >>> be begin working out the details. >> >> >> What is the most worrying is the exact "take over" process. Does it mean >> that the teams will give away the +2 power to a different team? Or will our >> (small) stable teams still be responsible for landing changes? If so, will >> they have to learn how to debug 3rd party CI jobs? >> >> Generally, I'm scared of both overloading the teams and losing the control >> over quality at the same time :) Probably the final proposal will clarify >> it.. > > > The quality of backported fixes is expected to be a direct (and only?) > interest of those new teams of new cores, coming from users and operators > and vendors. The more parties to establish their 3rd party checking jobs, > the better proposed changes communicated, which directly affects the quality > in the end. I also suppose, contributors from ops world will likely be only > struggling to see things getting fixed, and not new features adopted by > legacy deployments they're used to maintain. So in theory, this works and as > a mainstream developer and maintainer, you need no to fear of losing control > over LTS code :) > > Another question is how to not block all on each over, and not push > contributors away when things are getting awry, jobs failing and merging is > blocked for a long time, or there is no consensus reached in a code review. > I propose the LTS policy to enforce CI jobs be non-voting, as a first step > on that way, and giving every LTS team member a core rights maybe? Not sure > if that works though. > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > > __________________________________________________________________________ > 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 -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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
