<div dir="ltr"><div>Adding gluster-devel ML.</div><div><br></div><div>Only concern to my earlier proposal was not making regression runs wait for reviews, but to be triggered automatically after successful smoke. </div><div><br></div><div>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.</div><div> <br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 25, 2019 at 11:01 AM Sankarshan Mukhopadhyay <<a href="mailto:sankarshan.mukhopadhyay@gmail.com">sankarshan.mukhopadhyay@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Amar, can you bring about an agreement/decision on this so that we can<br>
make progress?<br>
<br></blockquote><div><br></div><div>So, My take is:</div><div><br></div><div>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.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Tue, Jun 25, 2019 at 10:55 AM Deepshikha Khandelwal<br>
<<a href="mailto:dkhandel@redhat.com" target="_blank">dkhandel@redhat.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Jun 24, 2019 at 5:30 PM Sankarshan Mukhopadhyay <<a href="mailto:sankarshan.mukhopadhyay@gmail.com" target="_blank">sankarshan.mukhopadhyay@gmail.com</a>> wrote:<br>
>><br>
>> Checking back on this - do we need more voices or, amendments to<br>
>> Amar's original proposal before we scope the implementation?<br>
>><br>
>> I read Amar's proposal as desiring an outcome where the journey of a<br>
>> valid/good patch through the test flows is fast and efficient.<br></blockquote><div><br></div><div>Absolutely! This is critical for us to be inclusive community.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>><br>
>> On Wed, Jun 12, 2019 at 11:58 PM Raghavendra Talur <<a href="mailto:rtalur@redhat.com" target="_blank">rtalur@redhat.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Wed, Jun 12, 2019, 1:56 PM Atin Mukherjee <<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>> wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Wed, 12 Jun 2019 at 18:04, Amar Tumballi Suryanarayan <<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>> wrote:<br>
>> >>><br>
>> >>><br>
>> >>> Few bullet points:<br>
>> >>><br>
>> >>> * Let smoke job sequentially for below, and if successful, in parallel for others.<br>
>> >>> - Sequential:<br>
>> >>> -- clang-format check<br>
>> >>> -- compare-bugzilla-version-git-branch<br>
>> >>> -- bugzilla-post<br>
>> >>> -- comment-on-issue<br>
>> >>> -- fedora-smoke (mainly don't want warning).<br>
>> >><br>
>> >><br>
>> >> +1<br>
>> >><br>
>> >>> - Parallel<br>
>> >>> -- all devrpm jobs<br>
>> >>> -- 32bit smoke<br>
>> >>> -- freebsd-smoke<br>
>> >>> -- smoke<br>
>> >>> -- strfmt_errors<br>
>> >>> -- python-lint, and shellcheck.<br>
>> >><br>
>> >><br>
>> >> 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?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> >><br>
>> >>><br>
>> >>> * Remove Verified flag. No point in one more extra button which users need to click, anyways CentOS regression is considered as 'Verification'.<br>
>> ><br>
>> ><br>
>> > 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.<br>
>><br>
>> However, do we consider that at present time the situation has<br>
>> improved to consider the change Amar asks for?<br>
>><br>
>> ><br>
>> >>><br>
>> >>> * In a normal flow, let CentOS regression which is running after 'Verified' vote, be triggered on first 'successful' +1 reviewed vote.<br>
>> >><br>
>> >><br>
>> >> 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.<br>
>> ><br>
>> ><br>
>> > Agree with Atin here. Burden should be on machines before people. Reviewers prefer to look at patches that have passed regression.<br>
>> ><br>
>> > 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.<br>
>> ><br>
>> > 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.<br>
>> ><br>
>><br>
>> Deepshikha, is the above change feasible in the summation of Amar's proposal?<br>
><br>
> Yes, I'm planning to implement the regression & flag related changes initially if everyone agrees.<br>
>><br>
>><br></blockquote><div><br></div><div>I would say, lets get started on these changes.</div><div><br></div><div>Regards,</div><div>Amar</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> >>><br>
>> >>> * 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.<br>
>> >>><br>
>> >>><br>
>> >>> 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).<br>
>> >>><br>
>> >>> Also we can reduce number of regression running, as review is mandatory to run regression.<br>
>> >>><br>
>> >>> These are just suggestions, happy to discuss more on these.<br>
>> _______________________________________________<br>
>> Gluster-infra mailing list<br>
>> <a href="mailto:Gluster-infra@gluster.org" target="_blank">Gluster-infra@gluster.org</a><br>
>> <a href="https://lists.gluster.org/mailman/listinfo/gluster-infra" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-infra</a><br>
<br>
<br>
<br>
-- <br>
sankarshan mukhopadhyay<br>
<<a href="https://about.me/sankarshan.mukhopadhyay" rel="noreferrer" target="_blank">https://about.me/sankarshan.mukhopadhyay</a>><br>
_______________________________________________<br>
Gluster-infra mailing list<br>
<a href="mailto:Gluster-infra@gluster.org" target="_blank">Gluster-infra@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-infra" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-infra</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div></div>