You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spark.apache.org by Sean Owen <so...@cloudera.com> on 2015/02/12 09:42:12 UTC
How to track issues that must wait for Spark 2.x in JIRA?
Patrick and I were chatting about how to handle several issues which
clearly need a fix, and are easy, but can't be implemented until a
next major release like Spark 2.x since it would change APIs.
Examples:
https://issues.apache.org/jira/browse/SPARK-3266
https://issues.apache.org/jira/browse/SPARK-3369
https://issues.apache.org/jira/browse/SPARK-4819
We could simply make version 2.0.0 in JIRA. Although straightforward,
it might imply that release planning has begun for 2.0.0.
The version could be called "2+" for now to better indicate its status.
There is also a "Later" JIRA resolution. Although resolving the above
seems a little wrong, it might be reasonable if we're sure to revisit
"Later", well, at some well defined later. The three issues above risk
getting lost in the shuffle.
We also wondered whether using "Later" is good or bad. It takes items
off the radar that aren't going to be acted on anytime soon -- and
there are lots of those right now. It might send a message that these
will be revisited when they are even less likely to if resolved.
Any opinions?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org
Re: How to track issues that must wait for Spark 2.x in JIRA?
Posted by Sean Owen <so...@cloudera.com>.
Let me start with a version "2+" tag and at least write in the
description that it's only for issues that are clearly to be fixed,
but must wait until 2.x.
On Thu, Feb 12, 2015 at 8:54 AM, Patrick Wendell <pw...@gmail.com> wrote:
> Yeah my preferred is also having a more open ended "2+" for issues
> that are clearly desirable but blocked by compatibility concerns.
>
> What I would really want to avoid is major feature proposals sitting
> around in our JIRA and tagged under some 2.X version. IMO JIRA isn't
> the place for thoughts about very-long-term things. When we get these,
> I'd be include to either close them as "won't fix" or "later".
>
> On Thu, Feb 12, 2015 at 12:47 AM, Reynold Xin <rx...@databricks.com> wrote:
>> It seems to me having a version that is 2+ is good for that? Once we move
>> to 2.0, we can retag those that are not going to be fixed in 2.0 as 2.0.1
>> or 2.1.0 .
>>
>> On Thu, Feb 12, 2015 at 12:42 AM, Sean Owen <so...@cloudera.com> wrote:
>>
>>> Patrick and I were chatting about how to handle several issues which
>>> clearly need a fix, and are easy, but can't be implemented until a
>>> next major release like Spark 2.x since it would change APIs.
>>> Examples:
>>>
>>> https://issues.apache.org/jira/browse/SPARK-3266
>>> https://issues.apache.org/jira/browse/SPARK-3369
>>> https://issues.apache.org/jira/browse/SPARK-4819
>>>
>>> We could simply make version 2.0.0 in JIRA. Although straightforward,
>>> it might imply that release planning has begun for 2.0.0.
>>>
>>> The version could be called "2+" for now to better indicate its status.
>>>
>>> There is also a "Later" JIRA resolution. Although resolving the above
>>> seems a little wrong, it might be reasonable if we're sure to revisit
>>> "Later", well, at some well defined later. The three issues above risk
>>> getting lost in the shuffle.
>>>
>>> We also wondered whether using "Later" is good or bad. It takes items
>>> off the radar that aren't going to be acted on anytime soon -- and
>>> there are lots of those right now. It might send a message that these
>>> will be revisited when they are even less likely to if resolved.
>>>
>>> Any opinions?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
>>> For additional commands, e-mail: dev-help@spark.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org
Re: How to track issues that must wait for Spark 2.x in JIRA?
Posted by Patrick Wendell <pw...@gmail.com>.
Yeah my preferred is also having a more open ended "2+" for issues
that are clearly desirable but blocked by compatibility concerns.
What I would really want to avoid is major feature proposals sitting
around in our JIRA and tagged under some 2.X version. IMO JIRA isn't
the place for thoughts about very-long-term things. When we get these,
I'd be include to either close them as "won't fix" or "later".
On Thu, Feb 12, 2015 at 12:47 AM, Reynold Xin <rx...@databricks.com> wrote:
> It seems to me having a version that is 2+ is good for that? Once we move
> to 2.0, we can retag those that are not going to be fixed in 2.0 as 2.0.1
> or 2.1.0 .
>
> On Thu, Feb 12, 2015 at 12:42 AM, Sean Owen <so...@cloudera.com> wrote:
>
>> Patrick and I were chatting about how to handle several issues which
>> clearly need a fix, and are easy, but can't be implemented until a
>> next major release like Spark 2.x since it would change APIs.
>> Examples:
>>
>> https://issues.apache.org/jira/browse/SPARK-3266
>> https://issues.apache.org/jira/browse/SPARK-3369
>> https://issues.apache.org/jira/browse/SPARK-4819
>>
>> We could simply make version 2.0.0 in JIRA. Although straightforward,
>> it might imply that release planning has begun for 2.0.0.
>>
>> The version could be called "2+" for now to better indicate its status.
>>
>> There is also a "Later" JIRA resolution. Although resolving the above
>> seems a little wrong, it might be reasonable if we're sure to revisit
>> "Later", well, at some well defined later. The three issues above risk
>> getting lost in the shuffle.
>>
>> We also wondered whether using "Later" is good or bad. It takes items
>> off the radar that aren't going to be acted on anytime soon -- and
>> there are lots of those right now. It might send a message that these
>> will be revisited when they are even less likely to if resolved.
>>
>> Any opinions?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
>> For additional commands, e-mail: dev-help@spark.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org
Re: How to track issues that must wait for Spark 2.x in JIRA?
Posted by Reynold Xin <rx...@databricks.com>.
It seems to me having a version that is 2+ is good for that? Once we move
to 2.0, we can retag those that are not going to be fixed in 2.0 as 2.0.1
or 2.1.0 .
On Thu, Feb 12, 2015 at 12:42 AM, Sean Owen <so...@cloudera.com> wrote:
> Patrick and I were chatting about how to handle several issues which
> clearly need a fix, and are easy, but can't be implemented until a
> next major release like Spark 2.x since it would change APIs.
> Examples:
>
> https://issues.apache.org/jira/browse/SPARK-3266
> https://issues.apache.org/jira/browse/SPARK-3369
> https://issues.apache.org/jira/browse/SPARK-4819
>
> We could simply make version 2.0.0 in JIRA. Although straightforward,
> it might imply that release planning has begun for 2.0.0.
>
> The version could be called "2+" for now to better indicate its status.
>
> There is also a "Later" JIRA resolution. Although resolving the above
> seems a little wrong, it might be reasonable if we're sure to revisit
> "Later", well, at some well defined later. The three issues above risk
> getting lost in the shuffle.
>
> We also wondered whether using "Later" is good or bad. It takes items
> off the radar that aren't going to be acted on anytime soon -- and
> there are lots of those right now. It might send a message that these
> will be revisited when they are even less likely to if resolved.
>
> Any opinions?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
> For additional commands, e-mail: dev-help@spark.apache.org
>
>