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 _______________________________________________ maintainers mailing list [email protected] https://lists.gluster.org/mailman/listinfo/maintainers
