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

[Shyam Ranganathan]

On 11/06/2018 10:27 AM, Kaleb S. KEITHLEY wrote:
> 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.

Yes, when the release is made, it will be closed CURRENTRELEASE with the
fixed in set as the release, as it happens today. (also see similar
response to Atin's question)

> 
> 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.)

The definition of NEXTRELEASE here is a question as I see it.

I assumed next release of the found in version, I think you mean next
release than the found in version. IOW, if bug is against 4.1 and marked
NEXTRELEASE it means fixed in 4.1.next or above as I understand it,
whereas your understanding is 5.x or above, right?

I do not know which is the right interpretation, not finding
documentation for the same at present.

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