Hey folks, So I wandered across the policy spec[0] for how we should be handling unbranched repository reviews and I would like to start a broader discussion around this topic. We've seen it several times over the recent history where a change in oooqe or tripleo-ci ends up affecting either a stable branch or an additional set of jobs that were not run on the change. I think it's unrealistic to run every possible job combination on every submission and it's also a giant waste of CI resources. I also don't necessarily agree that we should be using depends-on to prove things are fine for a given patch for the same reasons. That being said, we do need to minimize our risk for patches to these repositories.
At the PTG retrospective I mentioned component design structure[1] as something we need to be more aware of. I think this particular topic is one of those types of things where we could benefit from evaluating the structure and policy around these unbranched repositories to see if we can improve it. Is there a particular reason why we continue to try and support deployment of (at least) 3 or 4 different versions within a single repository? Are we adding new features that really shouldn't be consumed by these older versions such that perhaps it makes sense to actually create stable branches? Perhaps there are some other ideas that might work? Thanks, -Alex [0] https://review.openstack.org/#/c/478488/ [1] http://people.redhat.com/aschultz/denver-ptg/tripleo-ptg-retro.jpg __________________________________________________________________________ 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