Re: jira cleanup

[James Taylor <ja...@apache.org>]

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 <en...@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 <ja...@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 <en...@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 <ja...@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 <en...@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 <nd...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Lgtm
> > > > > >
> > > > > > On Friday, November 20, 2015, Enis Söztutar <en...@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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>