spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <so...@cloudera.com>
Subject Re: How to track issues that must wait for Spark 2.x in JIRA?
Date Thu, 12 Feb 2015 10:54:03 GMT
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 <pwendell@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 <rxin@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 <sowen@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


Mime
View raw message