On Wed, 2018-10-10 at 06:50 +0200, Mohammed Naser wrote: > Hi everyone! > > So I’ve been thinking of dropping the Xenial jobs to reduce our > overall impact in terms of gate usage in master because we don’t > support it. > > However, I was a bit torn on this because i realize that it’s > possible for us to write things and backport them only to find out > that they’d break under xenial which can be deployed with Rocky. > > Thoughts? Ideas? I was thinking maybe Lee an experimental job.. not > really sure on specifics but I’d like to bring in more feedback. > > Thanks, > Mohammed > _____________________________________________________________________ > _____ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hello, In the past we removed the jobs (ocata didn't have trusty jobs, IIRC), and made sure backports were still passing the gates of newton with trusty jobs voting. It may force a re-implementation in lower branches, but it is fine for me, as ansible versions also differ and might require re-implementation anyway. That said, we didn't have the flexibility we have now with Zuul v3, and making the jobs voting/nv/experimental. The middle ground would be to have a non-voting check job. It is fine, but it consumes resources for patches that aren't supposed to be backported, and therefore I think it's not the greatest solution. I like the "check experimental" part. It has an inconvenient: it relies on our good behaviour: When a bug is raised (so first element, we should not forget the bug link!) for backport, we should all keep in mind to check experimental before attempting the merge on the higher branch. That said, I still prefer the "check experimental" that nothing. You have my vote! Best regards, JP __________________________________________________________________________ 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