Amar, can you bring about an agreement/decision on this so that we can make progress?
On Tue, Jun 25, 2019 at 10:55 AM Deepshikha Khandelwal <dkhan...@redhat.com> wrote: > > > > On Mon, Jun 24, 2019 at 5:30 PM Sankarshan Mukhopadhyay > <sankarshan.mukhopadh...@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 <rta...@redhat.com> wrote: >> > >> > >> > >> > On Wed, Jun 12, 2019, 1:56 PM Atin Mukherjee <amukh...@redhat.com> wrote: >> >> >> >> >> >> >> >> On Wed, 12 Jun 2019 at 18:04, Amar Tumballi Suryanarayan >> >> <atumb...@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@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-infra -- sankarshan mukhopadhyay <https://about.me/sankarshan.mukhopadhyay> _______________________________________________ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
