<div><div dir="auto">Bit late to this, but I’m in favour of the proposal.</div></div><div dir="auto"><br></div><div dir="auto">The script change should only consider transitioning the bug status from POST to CLOSED NEXTRELEASE on master branch only. What’d be also ideal is to update the fixed in version in which this patch will land.</div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, 5 Nov 2018 at 21:39, Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018 at 5:05 PM Sankarshan Mukhopadhyay <<a href="mailto:sankarshan.mukhopadhyay@gmail.com" target="_blank">sankarshan.mukhopadhyay@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Nov 5, 2018 at 8:14 PM Yaniv Kaul <<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>> wrote:<br>
> On Mon, Nov 5, 2018 at 4:28 PM Niels de Vos <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>> wrote:<br>
>><br>
>> On Mon, Nov 05, 2018 at 05:31:26PM +0530, Pranith Kumar Karampuri wrote:<br>
>> > hi,<br>
>> > When we create a bz on master and clone it to the next release(In my<br>
>> > case it was release-5.0), after that release happens can we close the bz on<br>
>> > master with CLOSED NEXTRELEASE?<br>
><br>
><br>
> Since no one is going to verify it (right now, but I'm hopeful this will change in the future!), no point in keeping it open.<br>
> You could keep it open and move it along the process, and then close it properly when you release the next release.<br>
> It's kinda pointless if no one's going to do anything with it between MODIFIED to CLOSED.<br>
> I mean - assuming you move it to ON_QA - who's going to do the verification?<br>
><br>
> In oVirt, QE actually verifies upstream bugs, so there is value. They are also all appear in the release notes, with their status and so on.<br>
<br>
The Glusto framework is intended to accomplish this end, is it not?<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If the developer / QE engineer developed a test case for that BZ - that would be amazing!</div></div></div><div dir="ltr"><div class="gmail_quote"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Y.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div></div></div>
_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/maintainers</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">- Atin (atinm)</div>