<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018 at 8:59 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 09:43 AM, Yaniv Kaul wrote:<br>
> <br>
> <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 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 close<br>
> 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 this will<br>
> change in the future!), no point in keeping it open.<br>
> You could keep it open and move it along the process, and then close it<br>
> properly when you release the next release.<br>
> It's kinda pointless if no one's going to do anything with it between<br>
> MODIFIED to CLOSED.<br>
> I mean - assuming you move it to ON_QA - who's going to do the verification?<br>
<br>
The link provided by Niels is the "proper" process, but there are a few<br>
gotchas here (which are noted in the comments provided in this mail as<br>
well),<br>
<br>
- Moving from MODIFIED to ON_QA assumes/needs packages to be made<br>
available, these are made available only when we prepare for the<br>
release, else bug reporters or QE need to use nightly builds to verify<br>
the same<br>
<br>
- Further, once on ON_QA we are not getting these verified as Yaniv<br>
states, so moving this out of the ON_QA state would not happen, and the<br>
bug would stay in limbo here till the release is made with the<br>
unverified(?) fix<br>
<br>
Here is what happens automatically at present,<br>
<br>
- Bugs move to POST and MODIFIED states as patches against the same are<br>
posted and then merged (with the patch commit message stating it "Fixes"<br>
and not just "Updates" the bug)<br>
<br>
- From here on, when the bug lands in a release and the release notes<br>
are prepared to notify that the said bugs are fixed, these bugs are<br>
moved to CLOSED-CURRENTRELEASE (using the release tools scripts [2])<br>
<br>
The tool moving the bug to the CLOSED state, is in reality to catch any<br>
bugs that are not in the right state, ideally it would be correct to<br>
only move those bugs that are VERIFIED to the closed state, but again as<br>
stated, current manner of dealing with the bugs does not include a<br>
verification step.<br>
<br>
So the time a bug spends between MODIFIED to CLOSED, states that it is<br>
merged (into the said branch against which the bug is filed) and<br>
awaiting a release.<br>
<br>
Instead the suggestion is to reflect that state more clearly as<br>
CLOSED-NEXTRELEASE.<br>
<br>
The automation hence can change to the following,<br>
<br>
- Do not move to MODIFIED when the patch is merged, but move it to<br>
CLOSED-NEXTRELEASE<br>
<br>
- The release tools would change these to CLOSED-CURRENTRELEASE with the<br>
"fixed in" version set right, when the release is made<br>
<br>
The change would be constant for bugs against master and against release<br>
branches. If we need to specialize this for bugs on master to move to<br>
only MODIFIED till it is merged into a release branch, that calls for<br>
more/changed automation and also a definition of what NEXTRELEASE means<br>
when a bug is filed against a branch.<br>
<br>
IMO, a bug on master marked NEXTRELEASE, means it lands when a next<br>
major release is made, and a bug on a branch marked NEXTRELEASE is when<br>
the next major (time between branching and GA/.0 of the branch) or,<br>
minor release is made.<br>
<br>
If we go with the above, the only automation change is not to move bugs<br>
to MODIFIED, but just push it to CLOSED-NEXTRELEASE instead.<br>
<br>
Based on the current state of lacking verification, this change is possible.<br>
<br></blockquote><div><br></div><div>Yes, the above was in my mind. </div><div><br></div><div>Change the current script to update bug to CLOSED-NEXT_RELEASE instead of MODIFIED.</div><div><br></div><div>-Amar</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thoughts?<br>
<br>
> <br>
> In oVirt, QE actually verifies upstream bugs, so there is value. They<br>
> are also all appear in the release notes, with their status and so on.<br>
> Y.<br>
> <br>
> <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<br>
> <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>
> <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>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div></div>