Re: How to track issues that must wait for Spark 2.x in JIRA?
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 pwend...@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 r...@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-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: How to track issues that must wait for Spark 2.x in JIRA?
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 r...@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-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: How to track issues that must wait for Spark 2.x in JIRA?
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-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
