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

[Amar Tumballi]

I am in favor of this suggestion. Mainly because CLOSING a bug means some
metrics (like time to CLOSE etc) would look much better, and appropriate.
This way, we can reduce the clutter in bugzilla too, and while the script
runs after release, it can actually change the status to
CLOSED->NEXTRELEASE to CLOSED->CURRENT_RELEASE with actual release string.

-Amar

On Mon, Nov 5, 2018 at 7:58 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?
>
> 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/6cf8a68b/attachment.html>