[Gluster-infra] New workflow proposal for glusterfs repo

[Deepshikha Khandelwal]

On Mon, Jun 24, 2019 at 5:30 PM Sankarshan Mukhopadhyay <
sankarshan.mukhopadhyay at gmail.com> wrote:

> Checking back on this - do we need more voices or, amendments to
> Amar's original proposal before we scope the implementation?
>
> I read Amar's proposal as desiring an outcome where the journey of a
> valid/good patch through the test flows is fast and efficient.
>
> On Wed, Jun 12, 2019 at 11:58 PM Raghavendra Talur <rtalur at redhat.com>
> wrote:
> >
> >
> >
> > On Wed, Jun 12, 2019, 1:56 PM Atin Mukherjee <amukherj at redhat.com>
> wrote:
> >>
> >>
> >>
> >> On Wed, 12 Jun 2019 at 18:04, Amar Tumballi Suryanarayan <
> atumball at redhat.com> wrote:
> >>>
> >>>
> >>> Few bullet points:
> >>>
> >>> * Let smoke job sequentially for below, and if successful, in parallel
> for others.
> >>>   - Sequential:
> >>>   -- clang-format check
> >>>   -- compare-bugzilla-version-git-branch
> >>>   -- bugzilla-post
> >>>   -- comment-on-issue
> >>>   -- fedora-smoke (mainly don't want warning).
> >>
> >>
> >> +1
> >>
> >>>   - Parallel
> >>>    -- all devrpm jobs
> >>>    -- 32bit smoke
> >>>    -- freebsd-smoke
> >>>    -- smoke
> >>>    -- strfmt_errors
> >>>    -- python-lint, and shellcheck.
> >>
> >>
> >> I’m sure there must be a reason but would like to know that why do they
> need to be parallel? Can’t we have them sequentially to have similar
> benefits of the resource utilisation like above? Or are all these
> individual jobs are time consuming such that having them sequentially will
> lead the overall smoke job to consume much longer?
> >>
> >>>
> >>> * Remove Verified flag. No point in one more extra button which users
> need to click, anyways CentOS regression is considered as 'Verification'.
> >
> >
> > The requirement of verified flag by patch owner for regression to run
> was added because the number of Jenkins machines we had were few and
> patches being uploaded were many.
>
> However, do we consider that at present time the situation has
> improved to consider the change Amar asks for?
>
> >
> >>>
> >>> * In a normal flow, let CentOS regression which is running after
> 'Verified' vote, be triggered on first 'successful' +1 reviewed vote.
> >>
> >>
> >> As I believe some reviewers/maintainers (including me) would like to
> see the regression vote to put a +1/+2 in most of the patches until and
> unless they are straight forward ones. So although with this you’re
> reducing the burden of one extra click from the patch owner, but on the
> other way you’re introducing the same burden on the reviewers who would
> like to check the regression vote. IMHO, I don’t see much benefits in
> implementing this.
> >
> >
> > Agree with Atin here. Burden should be on machines before people.
> Reviewers prefer to look at patches that have passed regression.
> >
> > In github heketi, we have configured regression to run on all patches
> that are submitted by heketi developer group. If such configuration is
> possible in gerrit+Jenkins, we should definitely do it that way.
> >
> > For patches that are submitted by someone outside of the developer
> group, a maintainer should verify that the patch doesn't do anything
> harmful and mark the regression to run.
> >
>
> Deepshikha, is the above change feasible in the summation of Amar's
> proposal?
>
Yes, I'm planning to implement the regression & flag related changes
initially if everyone agrees.

>
> >>>
> >>> * For those patches which got pushed to system to just 'validate'
> behavior, to run sample tests, WIP patches, continue to support 'recheck
> centos'  comment message, so we can run without any vote. Let it not be the
> norm.
> >>>
> >>>
> >>> With this, I see that we can reduce smoke failures utilize 90% less
> resources for a patch which would fail smoke anyways. (ie, 95% of the smoke
> failures would be caught in first 10% of the resource, and time).
> >>>
> >>> Also we can reduce number of regression running, as review is
> mandatory to run regression.
> >>>
> >>> These are just suggestions, happy to discuss more on these.
> _______________________________________________
> Gluster-infra mailing list
> Gluster-infra at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-infra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-infra/attachments/20190625/35ac4258/attachment-0001.html>