<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 6, 2018 at 7:16 PM Shyam Ranganathan <<a href="mailto:srangana@redhat.com">srangana@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 11/05/2018 07:00 PM, Atin Mukherjee wrote:<br>
> Bit late to this, but I’m in favour of the proposal.<br>
> <br>
> The script change should only consider transitioning the bug status from<br>
> POST to CLOSED NEXTRELEASE on master branch only. What’d be also ideal<br>
> is to update the fixed in version in which this patch will land.<br>
<br>
2 things, based on my response to this thread,<br>
<br>
- Script will change this bug state for all branches, not just master. I<br>
do not see a reason to keep master special.<br>
<br>
- When moving the state to NEXTRELEASE I would not want to put in a<br>
fixed in version yet, as that may change/morph, instead it would be<br>
added (as it is now) when the release is made and the bug changed to<br>
CURRENTRELEASE.<br></blockquote><div><br></div><div>I can buy in the point of having the other branches also follow the same rule of bug status moving to NEXTRELEASE from POST (considering we're fine to run a script during the release of mass moving them to CURRENTRELEASE) but not having the fixed in version in the bugs which are with mainline branch may raise a question/concern on what exact version this bug is being addressed at? Or is it that the post release bug movement script also considers all the bugs fixed in the master branch as well?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In all, the only change is the already existing script moving a bug from<br>
POST to CLOSED-NEXTRELEASE instead of MODIFIED.<br>
<br>
> <br>
> On Mon, 5 Nov 2018 at 21:39, Yaniv Kaul <<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a><br>
> <mailto:<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>>> wrote:<br>
> <br>
> <br>
> <br>
> On Mon, Nov 5, 2018 at 5:05 PM Sankarshan Mukhopadhyay<br>
> <<a href="mailto:sankarshan.mukhopadhyay@gmail.com" target="_blank">sankarshan.mukhopadhyay@gmail.com</a><br>
> <mailto:<a href="mailto:sankarshan.mukhopadhyay@gmail.com" target="_blank">sankarshan.mukhopadhyay@gmail.com</a>>> wrote:<br>
> <br>
> On Mon, Nov 5, 2018 at 8:14 PM Yaniv Kaul <<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a><br>
> <mailto:<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><br>
> <mailto:<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<br>
> Karampuri wrote:<br>
> >> > hi,<br>
> >> > When we create a bz on master and clone it to the next<br>
> release(In my<br>
> >> > case it was release-5.0), after that release happens can we<br>
> 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<br>
> 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<br>
> close it properly when you release the next release.<br>
> > It's kinda pointless if no one's going to do anything with it<br>
> between MODIFIED to CLOSED.<br>
> > I mean - assuming you move it to ON_QA - who's going to do the<br>
> verification?<br>
> ><br>
> > In oVirt, QE actually verifies upstream bugs, so there is<br>
> value. They are also all appear in the release notes, with their<br>
> status and so on.<br>
> <br>
> The Glusto framework is intended to accomplish this end, is it not?<br>
> <br>
> <br>
> If the developer / QE engineer developed a test case for that BZ -<br>
> that would be amazing!<br>
> Y.<br>
> _______________________________________________<br>
> maintainers mailing list<br>
> <a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a> <mailto:<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>
> <br>
> -- <br>
> - Atin (atinm)<br>
> <br>
> <br>
> _______________________________________________<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>
> <br>
</blockquote></div></div>