On Nov 8, 2017 1:52 PM, "James E. Blair" <cor...@inaugust.com> wrote:
Erik McCormick <emccorm...@cirrusseven.com> writes: > On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair <cor...@inaugust.com> wrote: >> Erik McCormick <emccorm...@cirrusseven.com> writes: >> >>> 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. >> >> I regret that due to a conflict I was unable to attend this session. >> Can you elaborate on why third-party CI would be necessary for this, >> considering that upstream CI already exists on all active branches? > > Lack of infra resources, people are already maintaining their own > testing for old releases, and distribution of work across > organizations I think were the chief reasons. Someone else feel free > to chime in and expand on it. Which resources are lacking? I wasn't made aware of a shortage of upstream CI resources affecting stable branch work, but if there is, I'm sure we can address it -- this is a very important effort. It's not a matter of things lacking for today's release cadence and deprecation policy. That is working fine. The problems would come if you had to, say, continue to run it for Mitaka until Queens is released. The upstream CI system is also a collaboratively maintained system with folks from many organizations participating in it. Indeed we're now distributing its maintenance and operation into projects themselves. It seems like an ideal place for folks from different organizations to collaborate. Monty, as well as the Stable Branch cores, were in the room, so perhaps they can elaborate on this for us. I'm no expert on what can and cannot be done. -Jim
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
