[Gluster-infra] New workflow proposal for glusterfs repo

[Atin Mukherjee]

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'.
>
> * 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.


> * 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.
>
> -Amar
>
>
>
> _______________________________________________
> Gluster-infra mailing list
> Gluster-infra at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-infra

-- 
- Atin (atinm)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-infra/attachments/20190612/bc66986a/attachment.html>