<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 4:28 PM Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.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 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></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">You could keep it open and move it along the process, and then close it properly when you release the next release.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It's kinda pointless if no one's going to do anything with it between MODIFIED to CLOSED.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I mean - assuming you move it to ON_QA - who's going to do the verification?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yes, I think that can be done. Not sure what the advantage is, an<br>
explanation for this suggestion would be nice :)<br>
<br>
I am guessing it will be a little clearer for users that find the<br>
CLOSED/NEXTRELEASE bug? It would need the next major version in the<br>
"fixed in version" field too though (or 'git describe' after merging).<br>
<br>
If this gets done, someone will need to update the bug report lifecycle<br>
at <a href="https://docs.gluster.org/en/latest/Contributors-Guide/Bug-report-Life-Cycle/" rel="noreferrer" target="_blank">https://docs.gluster.org/en/latest/Contributors-Guide/Bug-report-Life-Cycle/</a><br>
<br>
Uhmm, actually, that page already mentions CLOSED/NEXTRELEASE!<br>
<br>
Niels<br>
</blockquote></div></div>