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

[Kaleb S. KEITHLEY]

On 11/6/18 9:27 AM, Shyam Ranganathan wrote:
> Here is the way I see it,
> - If you find a bug on master and want to know if it is
> present/applicable for a release, you chase it's clone against the release
> - The state of the cloned bug against the release, tells you if is is
> CURRENTRELEASE/NEXTRELEASE/or what not.
> 
> So referring to the bug on master, to determine state on which
> release(s) it is fixed in is not the way to find fixed state.
> 
> As a result,
> - A bug on master with NEXTRELEASE means next major release of master.
> 
> - A Bug on a release branch with NEXTRELEASE means, next major/minor
> release of the branch.
> 

For the record: I'm not in love with that.

I'd prefer that a BZ for a release branch get closed with CURRENTRELEASE
(meaning 4.1, 5, 6, etc.) and Fixed In: set to the specific version,
4.1.6 or 5.1, etc.

If a BZ on a release branch never gets fixed during the lifetime of that
branch (e.g. 4.1) it could/should be set to CLOSED/NEXTRELEASE (meaning
5 or later) when 4.1 reaches EOL. It could also be set to CLOSED/EOL,
but that implies, perhaps, that it won't be ever be fixed. I'd reserve
CLOSED/EOL for new bugs filed against versions that have already reached
EOL. (Clone the BZ to an active version if the bug exists there.)

I thought we were following kernel semantics. What are the kernel
semantics? Where are they described?

--

Kaleb