On Mon, Nov 5, 2018 at 8:59 PM Shyam Ranganathan <[email protected]> wrote:
> On 11/05/2018 09:43 AM, Yaniv Kaul wrote: > > > > > > On Mon, Nov 5, 2018 at 4:28 PM Niels de Vos <[email protected] > > <mailto:[email protected]>> 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? > > > > > > Since no one is going to verify it (right now, but I'm hopeful this will > > change in the future!), no point in keeping it open. > > You could keep it open and move it along the process, and then close it > > properly when you release the next release. > > It's kinda pointless if no one's going to do anything with it between > > MODIFIED to CLOSED. > > I mean - assuming you move it to ON_QA - who's going to do the > verification? > > The link provided by Niels is the "proper" process, but there are a few > gotchas here (which are noted in the comments provided in this mail as > well), > > - Moving from MODIFIED to ON_QA assumes/needs packages to be made > available, these are made available only when we prepare for the > release, else bug reporters or QE need to use nightly builds to verify > the same > > - Further, once on ON_QA we are not getting these verified as Yaniv > states, so moving this out of the ON_QA state would not happen, and the > bug would stay in limbo here till the release is made with the > unverified(?) fix > > Here is what happens automatically at present, > > - Bugs move to POST and MODIFIED states as patches against the same are > posted and then merged (with the patch commit message stating it "Fixes" > and not just "Updates" the bug) > > - From here on, when the bug lands in a release and the release notes > are prepared to notify that the said bugs are fixed, these bugs are > moved to CLOSED-CURRENTRELEASE (using the release tools scripts [2]) > > The tool moving the bug to the CLOSED state, is in reality to catch any > bugs that are not in the right state, ideally it would be correct to > only move those bugs that are VERIFIED to the closed state, but again as > stated, current manner of dealing with the bugs does not include a > verification step. > > So the time a bug spends between MODIFIED to CLOSED, states that it is > merged (into the said branch against which the bug is filed) and > awaiting a release. > > Instead the suggestion is to reflect that state more clearly as > CLOSED-NEXTRELEASE. > > The automation hence can change to the following, > > - Do not move to MODIFIED when the patch is merged, but move it to > CLOSED-NEXTRELEASE > > - The release tools would change these to CLOSED-CURRENTRELEASE with the > "fixed in" version set right, when the release is made > > The change would be constant for bugs against master and against release > branches. If we need to specialize this for bugs on master to move to > only MODIFIED till it is merged into a release branch, that calls for > more/changed automation and also a definition of what NEXTRELEASE means > when a bug is filed against a branch. > > IMO, a bug on master marked NEXTRELEASE, means it lands when a next > major release is made, and a bug on a branch marked NEXTRELEASE is when > the next major (time between branching and GA/.0 of the branch) or, > minor release is made. > > If we go with the above, the only automation change is not to move bugs > to MODIFIED, but just push it to CLOSED-NEXTRELEASE instead. > > Based on the current state of lacking verification, this change is > possible. > > Yes, the above was in my mind. Change the current script to update bug to CLOSED-NEXT_RELEASE instead of MODIFIED. -Amar > Thoughts? > > > > > In oVirt, QE actually verifies upstream bugs, so there is value. They > > are also all appear in the release notes, with their status and so on. > > Y. > > > > > > 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 > [email protected] > https://lists.gluster.org/mailman/listinfo/maintainers > -- Amar Tumballi (amarts)
_______________________________________________ maintainers mailing list [email protected] https://lists.gluster.org/mailman/listinfo/maintainers
