Following up - what is the agreed upon plan here? On Tue, Jun 25, 2019 at 11:20 AM Amar Tumballi Suryanarayan <[email protected]> wrote: > > Adding gluster-devel ML. > > Only concern to my earlier proposal was not making regression runs wait for > reviews, but to be triggered automatically after successful smoke. > > The ask was to put burden on machines than on developers, which I agree to > start with. Lets watch the expenses due to this change for a month once it > gets implemented, and then take stock of the situation. For now, lets reduce > one more extra work for developers, ie, marking Verified flag. > > On Tue, Jun 25, 2019 at 11:01 AM Sankarshan Mukhopadhyay > <[email protected]> wrote: >> >> Amar, can you bring about an agreement/decision on this so that we can >> make progress? >> > > So, My take is: > > Lets make serialized smoke + regression a reality. It may add to overall > time, but if there are failures, this has potential to reduce overall machine > usage... for a successful patch, the extra few minutes at present doesn't > harm as many of our review avg time is around a week. > > >> >> On Tue, Jun 25, 2019 at 10:55 AM Deepshikha Khandelwal >> <[email protected]> wrote: >> > >> > >> > >> > 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. > > > Absolutely! This is critical for us to be inclusive community. > >> >> >> >> >> 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? > > > Most of these are doing the same thing, make dist, make install, make rpms. > but on different arch and with different flags. To start with, we can do > these also sequentially. That way, infra team needn't worry about some > parallel, some sequential jobs. > >> >> >> >> >> >> >>> >> >> >>> * 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. >> >> >> >> > > > I would say, lets get started on these changes. > > Regards, > Amar > >> >> >> >>> >> >> >>> * 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 >> >> >> >> -- >> sankarshan mukhopadhyay >> <https://about.me/sankarshan.mukhopadhyay> >> _______________________________________________ >> Gluster-infra mailing list >> [email protected] >> https://lists.gluster.org/mailman/listinfo/gluster-infra > > > > -- > Amar Tumballi (amarts)
-- sankarshan mukhopadhyay <https://about.me/sankarshan.mukhopadhyay> _______________________________________________ Gluster-infra mailing list [email protected] https://lists.gluster.org/mailman/listinfo/gluster-infra
