Open Stack

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