Can we not manage this stuff on Jira?
On Fri, Sep 26, 2014 at 10:16 AM, Stephan Ewen <[email protected]> wrote: > I personally like the idea of SOFT time-based feature freezes. Otherwise, > releases will get delayed again and again, because of features that we try > to squeeze in. > > Having reached the freeze point already, we could still include the > features that are pending ready state in the next days (streaming, blob > Manager, POJOs), but otherwise head for a release state. > > We had a mail listing the issues to include into 0.7, but a wiki page would > probably be better. In that sense, we could start collecting the issues for > the next release from now on. > Am 26.09.2014 09:17 schrieb "Daniel Warneke" <[email protected]>: > >> Hi, >> >> I like Fabian's idea. Is there a wiki page (or something similar) where we >> can collect the proposed JIRAs? >> >> Best regards, >> >> Daniel >> >> Am 24.09.2014 23:03, schrieb Fabian Hueske: >> >>> I agree, a hard feature stop deadline might not be the best practice. >>> >>> How about the following procedure: >>> We decide two (or three) weeks before a targeted release date about which >>> JIRAs to include. JIRAs that are selected for a release should be >>> completed >>> or really close to completion (via progress estimates in JIRA). >>> After we decided which JIRAs to include in a release, we can use JIRA to >>> track the progress and dedicate another week exclusively for testing after >>> the last feature was completed. >>> >>> >>> 2014-09-24 19:10 GMT+02:00 Márton Balassi <[email protected]>: >>> >>> As for the streaming team we're also getting ready for the release, but a >>>> couple of days will be needed to finish the features that we would like >>>> to >>>> include. >>>> >>>> - A little work is still needed for reduce operations and >>>> groups/connected streams (any comment on Gyula's recent e-mail is >>>> really >>>> appreciated :) ) >>>> - The examples are being updated to match the standard, check out the >>>> WordCount. ( >>>> >>>> https://github.com/mbalassi/incubator-flink/blob/ >>>> streaming-new/flink-addons/flink-streaming/flink- >>>> streaming-examples/src/main/java/org/apache/flink/ >>>> streaming/examples/wordcount/WordCount.java >>>> ) >>>> Hopefully it gives you some deja vu. :) >>>> >>>> >>>> On Wed, Sep 24, 2014 at 6:53 PM, Ufuk Celebi <[email protected]> wrote: >>>> >>>> On 24 Sep 2014, at 18:37, Robert Metzger <[email protected]> wrote: >>>>> >>>>> Hey guys, >>>>>> >>>>>> exactly 3 weeks ago, we discussed to do a feature freeze for the >>>>>> 0.7-incubating release today. >>>>>> >>>>>> From our initial feature list: >>>>>> - *Flink Streaming* "Beta Preview". I would suggest to ship the >>>>>> >>>>> streaming, >>>>> >>>>>> but clearly mark it as a preview in the documentation. >>>>>> -* Java API Pojo improvements*: Code generation, key selection using a >>>>>> string-expression: https://issues.apache.org/jira/browse/FLINK-1032 >>>>>> - *Reworked Scala API*. Bring the Scala API in sync with the latest >>>>>> developments in the Java API: >>>>>> https://issues.apache.org/jira/browse/FLINK-641 >>>>>> -* Akka-based RPC service*: >>>>>> https://issues.apache.org/jira/browse/FLINK-1019 >>>>>> - *Kryo-based serialization*. This feature has been requested by many >>>>>> users. Mostly because they wanted to use Collections inside POJOs: >>>>>> https://issues.apache.org/jira/browse/FLINK-610 >>>>>> - Rework JobManager internals to support incremental program rollout & >>>>>> execution >>>>>> - First parts of dynamic memory assignments >>>>>> >>>>>> The following features are in the master, as of today: >>>>>> - *Flink Streaming* >>>>>> - *Reworked Scala API* >>>>>> -* New Scheduler* >>>>>> >>>>>> We certainly need some days to test everything until we can start the >>>>>> >>>>> vote. >>>>> >>>>>> Based on our experience with the last major release, I would really >>>>>> >>>>> like >>>> >>>>> to >>>>> >>>>>> do the testing and bugfixing BEFORE the first release candidate. For >>>>>> >>>>> the >>>> >>>>> 0.6-incubating release, we had 6 candidates) >>>>>> >>>>>> How do you guys feel about this? Should we wait a few more days for the >>>>>> release so that a few more features make it into the release? >>>>>> >>>>>> I'm undecided on this. On the one hand, its really nice to release on a >>>>>> regular schedule, but it also eats up some time and causes overhead >>>>>> (different branches etc.). >>>>>> I would really like to have the Java API Pojo improvements in the >>>>>> >>>>> release. >>>>> >>>>>> I think I can finish it until end of this week. >>>>>> >>>>>> Opinions? >>>>>> >>>>> I agree that the finished features (especially the Scala API) are nice >>>>> >>>> for >>>> >>>>> a new release, but still I would like to wait a few more days. >>>>> >>>>> Some of the missing features are on the brink of being finished (e.g. >>>>> the >>>>> Pojo improvements). I wouldn't want to invest a week in bug fixing and >>>>> doing the release vote, when the new features are likely to be finished >>>>> just a few days afterwards. And the upcoming features will definitely be >>>>> worth a release, so users can work with them. ;) >>>>> >>>> >>
