On Tue, Oct 10, 2017 at 2:24 PM, Emilien Macchi <emil...@redhat.com> wrote: > On Fri, Oct 6, 2017 at 5:09 AM, Jiří Stránský <ji...@redhat.com> wrote: >> 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. > > I agree a lot with Jirka and I think branching oooq-extras would be a > good first start to see how it goes. > If we find it helpful and working correctly, we could go the next > steps and see if there is any other repo that could be branched > (tripleo-ci or oooq) but I guess for now the best candidate is > oooq-extras. >
I'm resurrecting this thread as we seemed to have done it again[0] with a change oooq-extras master breaking stable/pike. So I would propose that we start investigating branching oooq-extras. Does anyone see any blocking issues with starting to branch this repository? Thanks, -Alex [0] https://bugs.launchpad.net/tripleo/+bug/1748315 >> (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-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> __________________________________________________________________________ >> 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 > > > > -- > Emilien Macchi > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
