Open Stack

On Thu, Feb 8, 2018 at 6:23 PM, Alex Schultz <aschultz at redhat.com> wrote:

> 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


 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-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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180209/f45064b5/attachment.html>