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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
