Process for marking Jira cases fixed and closed

[Julian Hyde <jh...@apache.org>]

I have been using the following process for marking issues fixed/closed.

* When a committer commits a patch to apache master, they must mark the
case fixed, set its fix version to the upcoming release, and add a comment
“Fixed in <commit URL including hash>” to the case.
* When the release is made, the release manager finds all issues marked
fixed with that release and closes them (see
https://github.com/apache/incubator-calcite/blob/master/doc/HOWTO.md#making-a-release-for-calcite-committers
)

As the release manager, I am currently doing the latter task, and I found a
few issues marked “fixed” without fix version. I am manually setting fix
version now.

Also, as we recently discussed on this list, committers can set the fix
version of open issues to “next”. This indicates the intention to fix these
issues in the next release, but it is not a commitment. If you are not a
committer, you must never set the fix version (even if jira allows you to).
You can vote for the issue or (the best vote of all!) contribute a patch.

OK with everyone?

Julian

Re: Process for marking Jira cases fixed and closed

[Vladimir Sitnikov <si...@gmail.com>]

+1

Vladimir

Re: Process for marking Jira cases fixed and closed

[Ted Dunning <te...@gmail.com>]

Sounds right.  May need to change when there are releases on multiple
branches pending.



On Fri, Feb 6, 2015 at 1:07 PM, Jacques Nadeau <ja...@apache.org> wrote:

> +1
>
> On Fri, Feb 6, 2015 at 11:50 AM, Julian Hyde <jh...@apache.org> wrote:
>
> > I have been using the following process for marking issues fixed/closed.
> >
> > * When a committer commits a patch to apache master, they must mark the
> > case fixed, set its fix version to the upcoming release, and add a
> comment
> > “Fixed in <commit URL including hash>” to the case.
> > * When the release is made, the release manager finds all issues marked
> > fixed with that release and closes them (see
> >
> >
> https://github.com/apache/incubator-calcite/blob/master/doc/HOWTO.md#making-a-release-for-calcite-committers
> > )
> >
> > As the release manager, I am currently doing the latter task, and I
> found a
> > few issues marked “fixed” without fix version. I am manually setting fix
> > version now.
> >
> > Also, as we recently discussed on this list, committers can set the fix
> > version of open issues to “next”. This indicates the intention to fix
> these
> > issues in the next release, but it is not a commitment. If you are not a
> > committer, you must never set the fix version (even if jira allows you
> to).
> > You can vote for the issue or (the best vote of all!) contribute a patch.
> >
> > OK with everyone?
> >
> > Julian
> >
>

Re: Process for marking Jira cases fixed and closed

[Jacques Nadeau <ja...@apache.org>]

+1

On Fri, Feb 6, 2015 at 11:50 AM, Julian Hyde <jh...@apache.org> wrote:

> I have been using the following process for marking issues fixed/closed.
>
> * When a committer commits a patch to apache master, they must mark the
> case fixed, set its fix version to the upcoming release, and add a comment
> “Fixed in <commit URL including hash>” to the case.
> * When the release is made, the release manager finds all issues marked
> fixed with that release and closes them (see
>
> https://github.com/apache/incubator-calcite/blob/master/doc/HOWTO.md#making-a-release-for-calcite-committers
> )
>
> As the release manager, I am currently doing the latter task, and I found a
> few issues marked “fixed” without fix version. I am manually setting fix
> version now.
>
> Also, as we recently discussed on this list, committers can set the fix
> version of open issues to “next”. This indicates the intention to fix these
> issues in the next release, but it is not a commitment. If you are not a
> committer, you must never set the fix version (even if jira allows you to).
> You can vote for the issue or (the best vote of all!) contribute a patch.
>
> OK with everyone?
>
> Julian
>