Open Stack

On Tue, Oct 10, 2017 at 2:24 PM, Emilien Macchi <emilien at redhat.com> wrote:
> On Fri, Oct 6, 2017 at 5:09 AM, Jiří Stránský <jistr at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev