On 11/06/2018 11:44 AM, Atin Mukherjee wrote: > > > On Tue, 6 Nov 2018 at 19:57, Shyam Ranganathan <srang...@redhat.com > <mailto:srang...@redhat.com>> wrote: > > On 11/06/2018 09:20 AM, Atin Mukherjee wrote: > > > > > > On Tue, Nov 6, 2018 at 7:16 PM Shyam Ranganathan > <srang...@redhat.com <mailto:srang...@redhat.com> > > <mailto:srang...@redhat.com <mailto:srang...@redhat.com>>> 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. > > > > - 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. > > > > > > 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? > > Here is the way I see it, > - If you find a bug on master and want to know if it is > present/applicable for a release, you chase it's clone against the > release > - The state of the cloned bug against the release, tells you if is is > CURRENTRELEASE/NEXTRELEASE/or what not. > > So referring to the bug on master, to determine state on which > release(s) it is fixed in is not the way to find fixed state. > > > Question : With this workflow what happens when a bug is just filed & > fixed only in master and comes as a fix to the next release as part of > branch out? So how would an user understand what release version is the > fix in if we don’t have a fixed in version?
I think the workflow is explained in my other longer mail, but for this question, the bug is moved from NEXTRELEASE->CURRENTRELEASE and the fixed in milestone is set. This happens even today, with bugs fixed in master that stay at MODIFIED and get CLOSED-CURRENTRELEASE with the fixed in milestone set to the release. > > > > As a result, > - A bug on master with NEXTRELEASE means next major release of master. > > - A Bug on a release branch with NEXTRELEASE means, next major/minor > release of the branch. > > > > > > > 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 <yk...@redhat.com > <mailto:yk...@redhat.com> > > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>> > > > <mailto:yk...@redhat.com <mailto:yk...@redhat.com> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>>> wrote: > > > > > > > > > > > > On Mon, Nov 5, 2018 at 5:05 PM Sankarshan Mukhopadhyay > > > <sankarshan.mukhopadh...@gmail.com > <mailto:sankarshan.mukhopadh...@gmail.com> > > <mailto:sankarshan.mukhopadh...@gmail.com > <mailto:sankarshan.mukhopadh...@gmail.com>> > > > <mailto:sankarshan.mukhopadh...@gmail.com > <mailto:sankarshan.mukhopadh...@gmail.com> > > <mailto:sankarshan.mukhopadh...@gmail.com > <mailto:sankarshan.mukhopadh...@gmail.com>>>> wrote: > > > > > > On Mon, Nov 5, 2018 at 8:14 PM Yaniv Kaul > > <yk...@redhat.com <mailto:yk...@redhat.com> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>> > > > <mailto:yk...@redhat.com <mailto:yk...@redhat.com> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>>> wrote: > > > > On Mon, Nov 5, 2018 at 4:28 PM Niels de Vos > > <nde...@redhat.com <mailto:nde...@redhat.com> > <mailto:nde...@redhat.com <mailto:nde...@redhat.com>> > > > <mailto:nde...@redhat.com <mailto:nde...@redhat.com> > <mailto:nde...@redhat.com <mailto:nde...@redhat.com>>>> 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 > > > maintainers@gluster.org <mailto:maintainers@gluster.org> > <mailto:maintainers@gluster.org <mailto:maintainers@gluster.org>> > > <mailto:maintainers@gluster.org > <mailto:maintainers@gluster.org> <mailto:maintainers@gluster.org > <mailto:maintainers@gluster.org>>> > > > https://lists.gluster.org/mailman/listinfo/maintainers > > > > > > -- > > > - Atin (atinm) > > > > > > > > > _______________________________________________ > > > maintainers mailing list > > > maintainers@gluster.org <mailto:maintainers@gluster.org> > <mailto:maintainers@gluster.org <mailto:maintainers@gluster.org>> > > > https://lists.gluster.org/mailman/listinfo/maintainers > > > > > > > -- > - Atin (atinm) _______________________________________________ maintainers mailing list maintainers@gluster.org https://lists.gluster.org/mailman/listinfo/maintainers