You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Andrew Wang <an...@cloudera.com> on 2017/05/01 21:27:41 UTC
Re: About 2.7.4 Release
I didn't close JIRAs after the 3.0.0-alpha1 or alpha2 releases since
closing makes the JIRAs read-only. This makes it more annoying to backport
to older releases and for concurrent releases in general.
I believe I asked about this on dev-yetus a while back. I'd prefer that the
presence of the fix version be sufficient to indicate whether a JIRA is
included in a release branch. Yetus requires that the JIRA be resolved as
"Fixed" to show up, which is why we are in our current situation.
On Thu, Apr 27, 2017 at 12:47 AM, Akira Ajisaka <aa...@apache.org> wrote:
> Thanks Allen for the additional information.
>
> > At one point, JIRA was configured to refuse re-opening after a release
> is cut.
>
> In the past, release manager closed the tickets and the process is written
> in the wiki: https://wiki.apache.org/hadoop/HowToRelease
>
> > 10. In JIRA, close issues resolved in the release. Disable mail
> notifications for this bulk change.
>
> Therefore, let's close them.
>
> On 2017/04/27 3:01, Allen Wittenauer wrote:
>
>>
>> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka <aa...@apache.org> wrote:
>>>
>>>> Maybe we should create a jira to track this?
>>>>
>>>
>>> I think now either way (reopen or create) is fine.
>>>
>>> Release doc maker creates change logs by fetching information from JIRA,
>>> so reopening the tickets should be avoided when a release process is in
>>> progress.
>>>
>>>
>> Keep in mind that the release documentation is part of the build
>> process. Users who are doing their own builds will have incomplete
>> documentation if we keep re-opening JIRAs after a release. At one point,
>> JIRA was configured to refuse re-opening after a release is cut. I'm not
>> sure why it stopped doing that, but it might be time to see if we can
>> re-enable that functionality.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
Can we wait for 2.7.4 first? There are still backports happening to
branch-2.7. After that, there shouldn't be many backports since both 2.8.x
and 2.7.x will be up-to-date with what's in 3.0.0-alpha1 and 3.0.0-alpha2.
On Tue, May 2, 2017 at 4:07 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> Is there any reason to not Close -alpha1+resolved state JIRAs? It's been
> quite a while and those definitely should not getting re-opened anymore.
> What about -alpha2's that are also resolved?
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
Can we wait for 2.7.4 first? There are still backports happening to
branch-2.7. After that, there shouldn't be many backports since both 2.8.x
and 2.7.x will be up-to-date with what's in 3.0.0-alpha1 and 3.0.0-alpha2.
On Tue, May 2, 2017 at 4:07 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> Is there any reason to not Close -alpha1+resolved state JIRAs? It's been
> quite a while and those definitely should not getting re-opened anymore.
> What about -alpha2's that are also resolved?
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
Can we wait for 2.7.4 first? There are still backports happening to
branch-2.7. After that, there shouldn't be many backports since both 2.8.x
and 2.7.x will be up-to-date with what's in 3.0.0-alpha1 and 3.0.0-alpha2.
On Tue, May 2, 2017 at 4:07 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> Is there any reason to not Close -alpha1+resolved state JIRAs? It's been
> quite a while and those definitely should not getting re-opened anymore.
> What about -alpha2's that are also resolved?
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
Can we wait for 2.7.4 first? There are still backports happening to
branch-2.7. After that, there shouldn't be many backports since both 2.8.x
and 2.7.x will be up-to-date with what's in 3.0.0-alpha1 and 3.0.0-alpha2.
On Tue, May 2, 2017 at 4:07 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> Is there any reason to not Close -alpha1+resolved state JIRAs? It's been
> quite a while and those definitely should not getting re-opened anymore.
> What about -alpha2's that are also resolved?
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
Is there any reason to not Close -alpha1+resolved state JIRAs? It's been quite a while and those definitely should not getting re-opened anymore. What about -alpha2's that are also resolved?
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
Is there any reason to not Close -alpha1+resolved state JIRAs? It's been quite a while and those definitely should not getting re-opened anymore. What about -alpha2's that are also resolved?
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
Is there any reason to not Close -alpha1+resolved state JIRAs? It's been quite a while and those definitely should not getting re-opened anymore. What about -alpha2's that are also resolved?
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
Is there any reason to not Close -alpha1+resolved state JIRAs? It's been quite a while and those definitely should not getting re-opened anymore. What about -alpha2's that are also resolved?
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
On Mon, May 1, 2017 at 3:44 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I believe I asked about this on dev-yetus a while back. I'd prefer that
> the presence of the fix version be sufficient to indicate whether a JIRA is
> included in a release branch. Yetus requires that the JIRA be resolved as
> "Fixed" to show up, which is why we are in our current situation.
>
> We can't do this because Hadoop is the only one that I've seen
> that sets Fix version at close time. Everyone else is setting fix version
> in place of target (which is a custom field, iirc).
>
> Let's see if I can revive the discussion over on a yetus list/jira. I
think it's easier to add a new flag to Yetus than changing the Hadoop JIRA
workflow, and it seems like this issue is becoming more acute.
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
On Mon, May 1, 2017 at 3:44 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I believe I asked about this on dev-yetus a while back. I'd prefer that
> the presence of the fix version be sufficient to indicate whether a JIRA is
> included in a release branch. Yetus requires that the JIRA be resolved as
> "Fixed" to show up, which is why we are in our current situation.
>
> We can't do this because Hadoop is the only one that I've seen
> that sets Fix version at close time. Everyone else is setting fix version
> in place of target (which is a custom field, iirc).
>
> Let's see if I can revive the discussion over on a yetus list/jira. I
think it's easier to add a new flag to Yetus than changing the Hadoop JIRA
workflow, and it seems like this issue is becoming more acute.
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
On Mon, May 1, 2017 at 3:44 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I believe I asked about this on dev-yetus a while back. I'd prefer that
> the presence of the fix version be sufficient to indicate whether a JIRA is
> included in a release branch. Yetus requires that the JIRA be resolved as
> "Fixed" to show up, which is why we are in our current situation.
>
> We can't do this because Hadoop is the only one that I've seen
> that sets Fix version at close time. Everyone else is setting fix version
> in place of target (which is a custom field, iirc).
>
> Let's see if I can revive the discussion over on a yetus list/jira. I
think it's easier to add a new flag to Yetus than changing the Hadoop JIRA
workflow, and it seems like this issue is becoming more acute.
Re: About 2.7.4 Release
Posted by Andrew Wang <an...@cloudera.com>.
On Mon, May 1, 2017 at 3:44 PM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I believe I asked about this on dev-yetus a while back. I'd prefer that
> the presence of the fix version be sufficient to indicate whether a JIRA is
> included in a release branch. Yetus requires that the JIRA be resolved as
> "Fixed" to show up, which is why we are in our current situation.
>
> We can't do this because Hadoop is the only one that I've seen
> that sets Fix version at close time. Everyone else is setting fix version
> in place of target (which is a custom field, iirc).
>
> Let's see if I can revive the discussion over on a yetus list/jira. I
think it's easier to add a new flag to Yetus than changing the Hadoop JIRA
workflow, and it seems like this issue is becoming more acute.
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com> wrote:
> I believe I asked about this on dev-yetus a while back. I'd prefer that the presence of the fix version be sufficient to indicate whether a JIRA is included in a release branch. Yetus requires that the JIRA be resolved as "Fixed" to show up, which is why we are in our current situation.
We can't do this because Hadoop is the only one that I've seen that sets Fix version at close time. Everyone else is setting fix version in place of target (which is a custom field, iirc).
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com> wrote:
> I believe I asked about this on dev-yetus a while back. I'd prefer that the presence of the fix version be sufficient to indicate whether a JIRA is included in a release branch. Yetus requires that the JIRA be resolved as "Fixed" to show up, which is why we are in our current situation.
We can't do this because Hadoop is the only one that I've seen that sets Fix version at close time. Everyone else is setting fix version in place of target (which is a custom field, iirc).
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com> wrote:
> I believe I asked about this on dev-yetus a while back. I'd prefer that the presence of the fix version be sufficient to indicate whether a JIRA is included in a release branch. Yetus requires that the JIRA be resolved as "Fixed" to show up, which is why we are in our current situation.
We can't do this because Hadoop is the only one that I've seen that sets Fix version at close time. Everyone else is setting fix version in place of target (which is a custom field, iirc).
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: About 2.7.4 Release
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On May 1, 2017, at 2:27 PM, Andrew Wang <an...@cloudera.com> wrote:
> I believe I asked about this on dev-yetus a while back. I'd prefer that the presence of the fix version be sufficient to indicate whether a JIRA is included in a release branch. Yetus requires that the JIRA be resolved as "Fixed" to show up, which is why we are in our current situation.
We can't do this because Hadoop is the only one that I've seen that sets Fix version at close time. Everyone else is setting fix version in place of target (which is a custom field, iirc).
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org