On Mon, Jun 24, 2019 at 5:30 PM Sankarshan Mukhopadhyay < [email protected]> 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 <[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? > 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 > [email protected] > https://lists.gluster.org/mailman/listinfo/gluster-infra
_______________________________________________ Gluster-infra mailing list [email protected] https://lists.gluster.org/mailman/listinfo/gluster-infra
