Re: [openstack-dev] [tripleo] Unbranched repositories and testing
On Thu, Feb 8, 2018 at 6:23 PM, Alex Schultz wrote: > On Tue, Oct 10, 2017 at 2:24 PM, Emilien Macchi > wrote: > > On Fri, Oct 6, 2017 at 5:09 AM, Jiří Stránský 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/lis
Re: [openstack-dev] [tripleo] Unbranched repositories and testing
On Tue, Oct 10, 2017 at 2:24 PM, Emilien Macchi wrote: > On Fri, Oct 6, 2017 at 5:09 AM, Jiří Stránský 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
Re: [openstack-dev] [tripleo] Unbranched repositories and testing
On Fri, Oct 6, 2017 at 5:09 AM, Jiří Stránský 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. > (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
Re: [openstack-dev] [tripleo] Unbranched repositories and testing
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-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-dev] [tripleo] Unbranched repositories and testing
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 __ 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
