Open Stack

On 5.10.2017 22:40, Alex Schultz wrote:
> 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?

Other folks probably have a better view of the full context here, but 
i'll chime in with my 2 cents anyway..

I think using stable branches for tripleo-quickstart-extras could be 
worth it. The content there is quite tightly coupled with the expected 
TripleO end-user workflows, which tend to evolve considerably between 
releases. Branching extras might be a good way to "match the reality" in 
that sense, and stop worrying about breaking older workflows. (Just 
recently it came up that the upgrade workflow in O is slightly updated 
to make it work in P, and will change quite a bit for Q. Minor updates 
also changed between O and P.)

I'd say that tripleo-quickstart is a different story though. It seems 
fairly release-agnostic in its focus. We may want to keep it unbranched 
(?). That probably applies even more for tripleo-ci, where ability to 
make changes which affect how TripleO does CIing in general, across 
releases, is IMO a significant feature.

Maybe branching quickstart-extras might require some code reshuffling 
between what belongs there and what belongs into quickstart itself.

(Just my 2 cents, i'm likely not among the most important stakeholders 
in this...)

Jirka

> 
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>