On 11/6/18 8:45 AM, Shyam Ranganathan wrote: > On 11/05/2018 07:00 PM, Atin Mukherjee wrote: >> Bit late to this, but I’m in favour of the proposal. >> >> 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. > > 2 things, based on my response to this thread, > > - Script will change this bug state for all branches, not just master. I > do not see a reason to keep master special.
But master is special. Or different anyway. At least the way we're using it it is. > > - When moving the state to NEXTRELEASE I would not want to put in a > fixed in version yet, as that may change/morph, instead it would be > added (as it is now) when the release is made and the bug changed to > CURRENTRELEASE. > > In all, the only change is the already existing script moving a bug from > POST to CLOSED-NEXTRELEASE instead of MODIFIED. > >> >> On Mon, 5 Nov 2018 at 21:39, Yaniv Kaul <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Mon, Nov 5, 2018 at 5:05 PM Sankarshan Mukhopadhyay >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Mon, Nov 5, 2018 at 8:14 PM Yaniv Kaul <[email protected] >> <mailto:[email protected]>> wrote: >> > On Mon, Nov 5, 2018 at 4:28 PM Niels de Vos <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Mon, Nov 05, 2018 at 05:31:26PM +0530, Pranith Kumar >> Karampuri wrote: >> >> > hi, >> >> > When we create a bz on master and clone it to the next >> release(In my >> >> > case it was release-5.0), after that release happens can we >> close the bz on >> >> > master with CLOSED NEXTRELEASE? >> > >> > >> > 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. >> > You could keep it open and move it along the process, and then >> close it properly when you release the next release. >> > It's kinda pointless if no one's going to do anything with it >> between MODIFIED to CLOSED. >> > I mean - assuming you move it to ON_QA - who's going to do the >> verification? >> > >> > 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. >> >> The Glusto framework is intended to accomplish this end, is it not? >> >> >> If the developer / QE engineer developed a test case for that BZ - >> that would be amazing! >> Y. >> _______________________________________________ >> maintainers mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gluster.org/mailman/listinfo/maintainers >> >> -- >> - Atin (atinm) >> >> >> _______________________________________________ >> maintainers mailing list >> [email protected] >> https://lists.gluster.org/mailman/listinfo/maintainers >> > _______________________________________________ > maintainers mailing list > [email protected] > https://lists.gluster.org/mailman/listinfo/maintainers > _______________________________________________ maintainers mailing list [email protected] https://lists.gluster.org/mailman/listinfo/maintainers
