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

[Shyam Ranganathan]

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.

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
>