<div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, 6 Nov 2018 at 19:57, 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/06/2018 09:20 AM, Atin Mukherjee wrote:<br>
> <br>
> <br>
> On Tue, Nov 6, 2018 at 7:16 PM Shyam Ranganathan <<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a><br>
> <mailto:<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>>> wrote:<br>
> <br>
> 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<br>
> 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>
> <br>
> <br>
> I can buy in the point of having the other branches also follow the same<br>
> rule of bug status moving to NEXTRELEASE from POST (considering we're<br>
> fine to run a script during the release of mass moving them to<br>
> CURRENTRELEASE) but not having the fixed in version in the bugs which<br>
> are with mainline branch may raise a question/concern on what exact<br>
> version this bug is being addressed at? Or is it that the post release<br>
> bug movement script also considers all the bugs fixed in the master<br>
> branch as well?<br>
<br>
Here is the way I see it,<br>
- If you find a bug on master and want to know if it is<br>
present/applicable for a release, you chase it's clone against the release<br>
- The state of the cloned bug against the release, tells you if is is<br>
CURRENTRELEASE/NEXTRELEASE/or what not.<br>
<br>
So referring to the bug on master, to determine state on which<br>
release(s) it is fixed in is not the way to find fixed state.</blockquote><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
As a result,<br>
- A bug on master with NEXTRELEASE means next major release of master.<br>
<br>
- A Bug on a release branch with NEXTRELEASE means, next major/minor<br>
release of the branch.<br>
<br>
> <br>
> <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>><br>
> > <mailto:<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a> <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>><br>
> > <mailto:<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<br>
> <<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a> <mailto:<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> <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<br>
> <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a> <mailto:<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> <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<br>
> next<br>
> > release(In my<br>
> > >> > case it was release-5.0), after that release happens<br>
> 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<br>
> 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,<br>
> 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<br>
> with it<br>
> > between MODIFIED to CLOSED.<br>
> > > I mean - assuming you move it to ON_QA - who's going to<br>
> 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<br>
> their<br>
> > status and so on.<br>
> ><br>
> > The Glusto framework is intended to accomplish this end,<br>
> 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>
> <mailto:<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> <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>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">- Atin (atinm)</div>