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 <[email protected]> wrote: > > > > On Wed, Jun 12, 2019, 1:56 PM Atin Mukherjee <[email protected]> wrote: >> >> >> >> On Wed, 12 Jun 2019 at 18:04, Amar Tumballi Suryanarayan >> <[email protected]> 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? >>> >>> * 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 [email protected] https://lists.gluster.org/mailman/listinfo/gluster-infra
