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

[Yaniv Kaul]

On Mon, Nov 5, 2018 at 4:28 PM Niels de Vos <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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20181105/834ddbcb/attachment.html>