You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@phoenix.apache.org by Enis Söztutar <en...@apache.org> on 2015/11/20 23:55:02 UTC

jira cleanup

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

Re: jira cleanup

Posted by 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: jira cleanup

Posted by Enis Söztutar <en...@apache.org>.

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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: jira cleanup

Posted by James Taylor <ja...@apache.org>.

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
> > > > >
> > > >
> > >
> >
>

Re: jira cleanup

Posted by Enis Söztutar <en...@gmail.com>.

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
> > > >
> > >
> >
>

Re: jira cleanup

Posted by James Taylor <ja...@apache.org>.

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
> > >
> >
>

Re: jira cleanup

Posted by Enis Söztutar <en...@apache.org>.

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
> >
>

Re: jira cleanup

Posted by Nick Dimiduk <nd...@gmail.com>.

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
>

Re: jira cleanup

Posted by James Taylor <ja...@apache.org>.

+1. Thanks, Enis.

On Fri, Nov 20, 2015 at 3:36 PM, Josh Mahonin <jm...@gmail.com> wrote:

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

Re: jira cleanup

Posted by Josh Mahonin <jm...@gmail.com>.

+1

On Fri, Nov 20, 2015 at 5:56 PM, Stack <st...@duboce.net> wrote:

> Sounds good to me.
> St.Ack
>
> On Fri, Nov 20, 2015 at 2:55 PM, 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
> >
>

Re: jira cleanup

Posted by Stack <st...@duboce.net>.

Sounds good to me.
St.Ack

On Fri, Nov 20, 2015 at 2:55 PM, 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
>