[ovirt-devel] [vdsm] branching out 4.1.2

[Eyal Edri]

On Mon, May 22, 2017 at 1:11 PM, Yedidyah Bar David <didi at redhat.com> wrote:

> On Mon, May 22, 2017 at 12:52 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
> >
> >
> > On Mon, May 22, 2017 at 11:23 AM, Francesco Romani <fromani at redhat.com>
> > wrote:
> >>
> >> Hi all,
> >>
> >>
> >> patches against the 4.1 branch are piling up, so I'm thinking about
> >> branching out 4.1.2 tomorrow (20170523)
> >>
> >> The activity on the 4.1.2 front was quite low lately, so we should
> >> expect quite few double backports.
> >>
> >>
> >> Thoughts? I'll go forward and branch if noone objects.
> >
> >
> > 1. Go for it.
> > 2. Let's see what the outcome is. How many 'merge races' we have, how
> many
> > regressions (hopefully none), how much work is poured into it,
>
> Do you want for the new branch full CI coverage?


I don't think it should, since the stable branch which is a superset of it
should all the patches as well and will fail
before backporting to the new branch.

Yes, there might be rare occasions where a patch will fail on version
branch and not stable branch,
I'm not sure its worth the effort of duplicating all CI resources per
branch just for it.
We already don't cover all flows in CI because there are limited resources,
so I don't see a huge difference here.

We can always run verification on the final bits via manual job before
releasing to catch such cases.


> Just branching takes a few
> seconds, and almost no resources (except for mental ones, in developers'
> minds). CI takes more time and more resources.
>
> > so we'll
> > learn from the future if we should branch sooner or is it OK to wait -
> and
> > until when.
>
> We had recently a private discussion about this, with no final conclusion
> AFAIR. I suggested (and repeat now) to fully automate this - so that
> project
> maintainers have in the gerrit UI checkboxes for CI per branch. This
> definitely
> takes time, and was considered not worth it, with the assumption that if
> we do
> our work well, we almost never need z branches - that we should aim to push
> and merge almost all the patches for some z version right after z-1 was
> released, and not postpone this to later on, when we already want to work
> on
> z+1 - and those late-comers that do want/need a branch should verify their
> patches manually and not need CI.
>
> > Y.
> >
> >>
> >>
> >>
> >> Bests,
> >>
> >> --
> >> Francesco Romani
> >> Senior SW Eng., Virtualization R&D
> >> Red Hat
> >> IRC: fromani github: @fromanirh
> >>
> >> _______________________________________________
> >> Devel mailing list
> >> Devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> --
> Didi
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>


-- 

Eyal edri


ASSOCIATE MANAGER

RHV DevOps

EMEA VIRTUALIZATION R&D


Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170522/37969731/attachment.html>