[Gluster-Maintainers] Bug state change proposal based on the conversation on bz 1630368

[Amar Tumballi]

On Mon, Nov 5, 2018 at 8:59 PM Shyam Ranganathan <srangana at redhat.com>
wrote:

> On 11/05/2018 09:43 AM, Yaniv Kaul wrote:
> >
> >
> > On Mon, Nov 5, 2018 at 4:28 PM Niels de Vos <ndevos at redhat.com
> > <mailto:ndevos at 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?
>
> The link provided by Niels is the "proper" process, but there are a few
> gotchas here (which are noted in the comments provided in this mail as
> well),
>
> - Moving from MODIFIED to ON_QA assumes/needs packages to be made
> available, these are made available only when we prepare for the
> release, else bug reporters or QE need to use nightly builds to verify
> the same
>
> - Further, once on ON_QA we are not getting these verified as Yaniv
> states, so moving this out of the ON_QA state would not happen, and the
> bug would stay in limbo here till the release is made with the
> unverified(?) fix
>
> Here is what happens automatically at present,
>
> - Bugs move to POST and MODIFIED states as patches against the same are
> posted and then merged (with the patch commit message stating it "Fixes"
> and not just "Updates" the bug)
>
> - From here on, when the bug lands in a release and the release notes
> are prepared to notify that the said bugs are fixed, these bugs are
> moved to CLOSED-CURRENTRELEASE (using the release tools scripts [2])
>
> The tool moving the bug to the CLOSED state, is in reality to catch any
> bugs that are not in the right state, ideally it would be correct to
> only move those bugs that are VERIFIED to the closed state, but again as
> stated, current manner of dealing with the bugs does not include a
> verification step.
>
> So the time a bug spends between MODIFIED to CLOSED, states that it is
> merged (into the said branch against which the bug is filed) and
> awaiting a release.
>
> Instead the suggestion is to reflect that state more clearly as
> CLOSED-NEXTRELEASE.
>
> The automation hence can change to the following,
>
> - Do not move to MODIFIED when the patch is merged, but move it to
> CLOSED-NEXTRELEASE
>
> - The release tools would change these to CLOSED-CURRENTRELEASE with the
> "fixed in" version set right, when the release is made
>
> The change would be constant for bugs against master and against release
> branches. If we need to specialize this for bugs on master to move to
> only MODIFIED till it is merged into a release branch, that calls for
> more/changed automation and also a definition of what NEXTRELEASE means
> when a bug is filed against a branch.
>
> IMO, a bug on master marked NEXTRELEASE, means it lands when a next
> major release is made, and a bug on a branch marked NEXTRELEASE is when
> the next major (time between branching and GA/.0 of the branch) or,
> minor release is made.
>
> If we go with the above, the only automation change is not to move bugs
> to MODIFIED, but just push it to CLOSED-NEXTRELEASE instead.
>
> Based on the current state of lacking verification, this change is
> possible.
>
>
Yes, the above was in my mind.

Change the current script to update bug to CLOSED-NEXT_RELEASE instead of
MODIFIED.

-Amar


> Thoughts?
>
> >
> > 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.
> > Y.
> >
> >
> >     Yes, I think that can be done. Not sure what the advantage is, an
> >     explanation for this suggestion would be nice :)
> >
> >     I am guessing it will be a little clearer for users that find the
> >     CLOSED/NEXTRELEASE bug? It would need the next major version in the
> >     "fixed in version" field too though (or 'git describe' after
> merging).
> >
> >     If this gets done, someone will need to update the bug report
> lifecycle
> >     at
> >
> https://docs.gluster.org/en/latest/Contributors-Guide/Bug-report-Life-Cycle/
> >
> >     Uhmm, actually, that page already mentions CLOSED/NEXTRELEASE!
> >
> >     Niels
> >
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>


-- 
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20181105/4e404465/attachment.html>