FYI, https://issues.apache.org/jira/browse/INFRA-10817 is resolved. Now the workflow is no-reopen-closed.
In HBase and Hadoop, we are using the fixVersion to track open issues against a release, so that the release manager (and others) can get an idea of what issues are open against that release (for example tracking the blockers and criticals). Nearing a release cut, the release manager actively moves the issues out of the release to the next version so that they do not block the release and at the time of the release, and ensure that there is no open jiras with fixVersion set for that. It has worked fine in communities I have been involved with. In Phoenix we can follow a similar model, or chose a different one as long as it is explicit and understood by the committers it should be fine. Enis On Sat, Nov 21, 2015 at 10:09 AM, James Taylor <[email protected]> wrote: > One small issue is that I see a number of JIRAs that are marked with a > fixVersion of 4.7.0 but have not yet been fixed. We typically only set the > fixVersion when a fix has been committed. I'll go through these are clear > this field out for unresolved issues. > > Thanks, > James > > On Fri, Nov 20, 2015 at 6:32 PM, Enis Söztutar <[email protected]> wrote: > > > James, that makes sense, opened > > https://issues.apache.org/jira/browse/PHOENIX-2442 for that. > > > > I also closed all issues matching this filter (881 in total): > > project = PHOENIX AND fixVersion in releasedVersions() and status in > > (resolved,closed) order by fixVersion DESC > > > > Enis > > > > > > On Fri, Nov 20, 2015 at 5:42 PM, James Taylor <[email protected]> > > wrote: > > > > > Thanks so much, Enis. These are super helpful. Do you think we should > add > > > these best practices to our "How to do a release" page? [1] > > > > > > James > > > > > > [1] http://phoenix.apache.org/release.html > > > > > > On Fri, Nov 20, 2015 at 5:39 PM, Enis Söztutar <[email protected]> > wrote: > > > > > > > Thanks guys, > > > > > > > > I did these changes: > > > > - Renamed X.Y -> X.Y.0 > > > > - Renamed X.Y-Release -> X.Y.0 > > > > - Created 4.6.1 > > > > - Released most of the versions in jira. The current unreleased ones > > > should > > > > correspond to reality (as much as I can tell). It would be good if > > > somebody > > > > can verify. > > > > > > > > > > > > > > https://issues.apache.org/jira/plugins/servlet/project-config/PHOENIX/versions > > > > . > > > > - Did not add release dates to jira. It maybe helpful. > > > > - Created https://issues.apache.org/jira/browse/INFRA-10817 for the > > > > workflow change. > > > > > > > > A couple of suggestions we can follow in Phoenix (from best practices > > in > > > > HBase and Hadoop community): > > > > - Committers should be careful and always mark correct fixVersions > > when > > > an > > > > issue is committed. The fixVersion should contain the next scheduled > > > > release from branches that the fix is committed. This one is pretty > > > > important, since it is the only way to cleanly see what issues 4.6.1 > > > > contains over 4.6.0 for example. > > > > - Always make sure that issues are resolved after commit. > > > > - The release manager should make sure that > > > > -- All issues in that release have a jira with correct fixVersion. > > > > -- Make sure that all jiras with fixVersion=X.Y.Z is either > resolved > > or > > > > moved out of the release before cutting the RC. > > > > -- Create X.Y.Z+1 as a release version in jira > > > > -- After the release, do a double check that no new issue is marked > > > with > > > > fixVersion=X.Y.Z (since it was not in the release). > > > > -- After the release, close all the jiras. For doing that, do a > jira > > > > search like this: > > > > > > > > project = PHOENIX AND fixVersion = X.Y.Z ORDER BY priority DESC > > > > Tools -> Bulk change -> Transition issues -> close > > > > comment: Closing this issue after 1.0.2 release. > > > > uncheck send mail > > > > > > > > > > > > Happy Friday, > > > > Enis > > > > > > > > > > > > On Fri, Nov 20, 2015 at 4:18 PM, Nick Dimiduk <[email protected]> > > > wrote: > > > > > > > > > Lgtm > > > > > > > > > > On Friday, November 20, 2015, Enis Söztutar <[email protected]> > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > It seems that we need some cleaning in the jira. I can do these > > > changes > > > > > if > > > > > > it is ok with everyone. > > > > > > > > > > > > 1. Versions with typos are there (4.60, etc). Jira will > auto-create > > > > these > > > > > > release versions if one types it in fixVersions. I'll remove > these. > > > > > > > > > > > > 2. 4.6.0 is released, but not released in Apache. We should > > "release" > > > > > that > > > > > > version in jira so that future issues cannot be tagged with that > > > > release > > > > > > version. We (in HBase) documented that to be a part of the > release > > > > > > management process. Looking at > > > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/plugins/servlet/project-config/PHOENIX/versions > > > > > > > > > > > > I don't see any versions that is "released" in jira. I think we > > > should > > > > > mark > > > > > > every version as released that corresponds to an actual release. > > > > > > > > > > > > 3. Best practice is to close all the jiras in the release, so > that > > > they > > > > > > cannot be reopened and changed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/PHOENIX-2244?jql=project%20%3D%20PHOENIX%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%204.6.0%20ORDER%20BY%20priority%20DESC > > > > > > > > > > > > 4. jira Workflow: change it to "no-reopen-closed". This workflow > is > > > > > safer, > > > > > > and used in HBase and Hadoop. The jiras in closed state cannot be > > > > > > re-opened. if we make sure to close all the jiras after a > release, > > > the > > > > > list > > > > > > of jiras committed and marked for that fixVersion becomes final. > > If a > > > > > patch > > > > > > for the jira is released in a version, then only creating a new > > jira > > > > will > > > > > > be the way to change. This makes issue and patch tracking for > > > releases > > > > > > easier I think. > > > > > > > > > > > > Let me know whether these makes sense or not. > > > > > > > > > > > > Enis > > > > > > > > > > > > > > > > > > > > >
