<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 8, 2018 at 6:23 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Oct 10, 2017 at 2:24 PM, Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br>
> On Fri, Oct 6, 2017 at 5:09 AM, Jiří Stránský <<a href="mailto:jistr@redhat.com">jistr@redhat.com</a>> wrote:<br>
>> On 5.10.2017 22:40, Alex Schultz wrote:<br>
>>><br>
>>> Hey folks,<br>
>>><br>
>>> So I wandered across the policy spec[0] for how we should be handling<br>
>>> unbranched repository reviews and I would like to start a broader<br>
>>> discussion around this topic. We've seen it several times over the<br>
>>> recent history where a change in oooqe or tripleo-ci ends up affecting<br>
>>> either a stable branch or an additional set of jobs that were not run<br>
>>> on the change. I think it's unrealistic to run every possible job<br>
>>> combination on every submission and it's also a giant waste of CI<br>
>>> resources. I also don't necessarily agree that we should be using<br>
>>> depends-on to prove things are fine for a given patch for the same<br>
>>> reasons. That being said, we do need to minimize our risk for patches<br>
>>> to these repositories.<br>
>>><br>
>>> At the PTG retrospective I mentioned component design structure[1] as<br>
>>> something we need to be more aware of. I think this particular topic<br>
>>> is one of those types of things where we could benefit from evaluating<br>
>>> the structure and policy around these unbranched repositories to see<br>
>>> if we can improve it. Is there a particular reason why we continue to<br>
>>> try and support deployment of (at least) 3 or 4 different versions<br>
>>> within a single repository? Are we adding new features that really<br>
>>> shouldn't be consumed by these older versions such that perhaps it<br>
>>> makes sense to actually create stable branches? Perhaps there are<br>
>>> some other ideas that might work?<br>
>><br>
>><br>
>> Other folks probably have a better view of the full context here, but i'll<br>
>> chime in with my 2 cents anyway..<br>
>><br>
>> I think using stable branches for tripleo-quickstart-extras could be worth<br>
>> it. The content there is quite tightly coupled with the expected TripleO<br>
>> end-user workflows, which tend to evolve considerably between releases.<br>
>> Branching extras might be a good way to "match the reality" in that sense,<br>
>> and stop worrying about breaking older workflows. (Just recently it came up<br>
>> that the upgrade workflow in O is slightly updated to make it work in P, and<br>
>> will change quite a bit for Q. Minor updates also changed between O and P.)<br>
>><br>
>> I'd say that tripleo-quickstart is a different story though. It seems fairly<br>
>> release-agnostic in its focus. We may want to keep it unbranched (?). That<br>
>> probably applies even more for tripleo-ci, where ability to make changes<br>
>> which affect how TripleO does CIing in general, across releases, is IMO a<br>
>> significant feature.<br>
>><br>
>> Maybe branching quickstart-extras might require some code reshuffling<br>
>> between what belongs there and what belongs into quickstart itself.<br>
><br>
> I agree a lot with Jirka and I think branching oooq-extras would be a<br>
> good first start to see how it goes.<br>
> If we find it helpful and working correctly, we could go the next<br>
> steps and see if there is any other repo that could be branched<br>
> (tripleo-ci or oooq) but I guess for now the best candidate is<br>
> oooq-extras.<br>
><br>
<br>
</div></div>I'm resurrecting this thread as we seemed to have done it again[0]<br>
with a change oooq-extras master breaking stable/pike. So I would<br>
propose that we start investigating branching oooq-extras. Does<br>
anyone see any blocking issues with starting to branch this<br>
repository?<br>
<br>
Thanks,<br>
-Alex<br>
<br>
[0] <a href="https://bugs.launchpad.net/tripleo/+bug/1748315" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>tripleo/+bug/1748315</a></blockquote><div><br></div><div> Thanks Alex,</div><div>TripleO-CI please be prepared to discuss this thread in the next scrum meeting.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
>> (Just my 2 cents, i'm likely not among the most important stakeholders in<br>
>> this...)<br>
>><br>
>> Jirka<br>
>><br>
>><br>
>>><br>
>>> Thanks,<br>
>>> -Alex<br>
>>><br>
>>> [0] <a href="https://review.openstack.org/#/c/478488/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/478488/</a><br>
>>> [1] <a href="http://people.redhat.com/aschultz/denver-ptg/tripleo-ptg-retro.jpg" rel="noreferrer" target="_blank">http://people.redhat.com/<wbr>aschultz/denver-ptg/tripleo-<wbr>ptg-retro.jpg</a><br>
>>><br>
>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
><br>
> --<br>
> Emilien Macchi<br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>