Open Stack

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.

> (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