+1 On Fri, Nov 20, 2015 at 5:56 PM, Stack <[email protected]> wrote:
> Sounds good to me. > St.Ack > > On Fri, Nov 20, 2015 at 2:55 PM, 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 > > >
