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

[Shyam Ranganathan]

On 11/06/2018 12:22 PM, Shyam Ranganathan wrote:
> 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.)

Adding some more on EOL.

What happened till before 3.12 was EOLd, was that all bugs that were not
CLOSED, were marked CLOSED-EOL. This was a problem as some bugs were not
even triaged or looked at.

>From 3.12 we are looking at bugs that are still OPEN and moving them to
"found in" master if they were not triaged or followed up to
satisfaction. Bugs, that have workarounds or request for data etc. are
closed EOL with a request to reproduce with an supported release and
reopen the bug as appropriate. As is obvious there is some manual work
involved here.

So in short CLOSED-EOL is used for older bugs as well, when it goes
nowhere in terms of root causing.

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