On Thu, Feb 8, 2018 at 6:23 PM, Alex Schultz <aschu...@redhat.com> wrote:
> 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 Thanks Alex, TripleO-CI please be prepared to discuss this thread in the next scrum meeting. > > > > >> (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 >
__________________________________________________________________________ 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