That process makes sense, Enis. Let's try to do that going forward if there are no objections.
On Mon, Nov 23, 2015 at 12:03 PM, Enis Söztutar <e...@apache.org> wrote: > 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 <jamestay...@apache.org> > 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 <enis....@gmail.com> > 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 <jamestay...@apache.org> > > > 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 <e...@apache.org> > > 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 <ndimi...@gmail.com> > > > > wrote: > > > > > > > > > > > Lgtm > > > > > > > > > > > > On Friday, November 20, 2015, Enis Söztutar <e...@apache.org> > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >