I'm +0 on switching to a pre-determined schedule. It may be that the Flink codebase has reached a level of maturity allowing for a time-based release schedule, and I'm hopeful that a known schedule will improve communication about and expectations for new features.
I'd like to hear a retrospective on the duration of the 1.2 release cycle. As noted recently within the Flink community, the number of outstanding pull requests and tickets has steadily increased. I'm concerned that with fixed deadlines committer priorities will take precedence and community contributions will be deferred indefinitely. I'm concerned that only blockers are fixed for a .0 release, and that exactly two weeks are allotted. Will any desirable fix simply become a blocker or will we potentially release with a list of known bugs? I think it would be worthwhile to identity upgradeable dependencies at the beginning of each release cycle which would allow the most time for testing during development. There are 130 open tickets scheduled for 1.2.0 [1]. Targeting "inbox zero" (without simply bulk-migrating tickets to another release) would be preferable to tracking tickets through email chains on the mailing list. The number of open GitHub pull requests isn't so much as issue since PRs are simply listed by date, but it would be helpful to keep Jira tickets up-to-date. It seems that "Fix Version" is often a wish rather than a plan. Greg [1] https://issues.apache.org/jira/browse/FLINK?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel On Wed, Jan 18, 2017 at 5:13 AM, Robert Metzger <rmetz...@apache.org> wrote: > Thanks a lot for the positive feedback so far. > > Thank you Fabian for spotting the off by one error in my email. > "There are two hard things in computer science: cache invalidation, naming > things, and off-by-one errors." (https://twitter.com/codinghorror/status/ > 506010907021828096?lang=en) > > I agree with Fabian that this model could potentially lead to more feature > branches in our repository. However, I think we should only do that for > major features where many contributors are collaborating on. Using private > development branches works equally well for smaller groups. > I found that the frequent "flip6" branch rebases caused a lot of noise on > the commits@flink list. > > Regarding the "bugfix guarantees": > I agree that my proposal doesn't make so much sense. I actually got the > same feedback from a draft of my email but forgot to change it before > sending it out. I think supporting the current (1.1) and previous (1.0) > major release is a doable guarantee. > > > > > On Wed, Jan 18, 2017 at 10:25 AM, Vasiliki Kalavri < > vasilikikala...@gmail.com> wrote: > > > Hi Robert, > > > > thanks a lot for starting this discussion and for putting together the > wiki > > pages. > > This proposal makes a lot of sense to me. > > > > Big +1 for merging only features which are tested and *documented*. > > > > I believe that having a clear timeline will not only make users happier > but > > also contributors more engaged. With the current unpredictability, it is > > hard to book time aside to help with testing a release candidate. I hope > > that knowing exactly when that needs to happen will help us plan our own > > time better and help out more. > > > > Cheers, > > -Vasia. > > > > On 18 January 2017 at 09:57, Tzu-Li (Gordon) Tai <tzuli...@apache.org> > > wrote: > > > > > Hi Robert, > > > > > > Thanks for bringing up the discussion. I like the proposal. > > > > > > Regarding some of the downsides mentioned in the wiki: > > > > > > 1. Features that don’t make it in time with the feature freeze: > > > I think that’s ok, as long as we’re consistent with the schedules for > the > > > next release. This way users waiting for that particular features will > > > still be able to rely on the fact that the feature will be included in > 4 > > > months. > > > > > > 2. Frequent releases mean bug fix releases for older branches: > > > You mentioned in the email that “old releases are supported for 6 > months > > > by the community”, but not in the wiki. If this is strictly followed, > > that > > > means we’ll at most be supporting 2 previous major release versions > (ex. > > as > > > soon as 1.4.0 comes out, we’ll still be supporting bugfixes for 1.3.0, > as > > > well as 1.2.0 for another 2 months). > > > This might seem a bit odd, so perhaps we can stick to something like > > > “support bugfixes for the previous 2 major releases”? Ex. Once 1.4.0 > > comes > > > out, we’ll continue to support only 1.4.0 and 1.3.0. > > > Supporting bugfixes for 2 major versions seems workable, and this way > > > users can also have a “buffer” that they should not fall behind > releases > > > for more than 2 major versions (8 months) and preplan upgrades. > > > > > > - Gordon > > > > > > On January 18, 2017 at 9:19:41 AM, Robert Metzger (rmetz...@apache.org > ) > > > wrote: > > > > > > Hi all! > > > > > > Since the 1.2.0 release is about to come out, I would like to propose a > > > change in the way we do releases in the Flink community. > > > > > > In my opinion, the current model leads to dissatisfaction among users > and > > > contributors, because releases are really not predictable. A recent > > example > > > for the issues with our current model are the FLIP-6 changes we wanted > to > > > merge to master, a few weeks before the first RC for 1.2.0. Also, there > > > were some emails on the mailing lists asking for a release date. > > > > > > In order to change that, I’m proposing to follow a strictly time-based > > > release model. Other open source projects like Ubuntu, Cassandra, Spark > > or > > > Kafka are following that model as well, and I think we should try it > out > > as > > > an experiment for the 1.3.0 release. > > > > > > I’m proposing to: > > > > > > - > > > > > > Do a Flink release every 4 months > > > - > > > > > > Cycle: > > > - > > > > > > 3 months development > > > - > > > > > > 1 month before the release: Feature freeze. Create release branch > > > with RC0, start testing. Only fixes, tests and minor improvements are > > > allowed in. > > > - > > > > > > 2 weeks before the release: Code freeze. Start voting. Only fixes for > > > blockers are allowed in. > > > - > > > > > > Forbid blocking a release because a feature is not done yet. > > > - > > > > > > Features are merged to master, when they are tested and documented, to > > > have an always stable master > > > - > > > > > > Bugfix releases are done as needed. > > > - > > > > > > Old releases are supported for 6 months by the Flink community with > > > critical bug fixes > > > > > > > > > This means, that we would have the following release dates: > > > > > > (Flink 1.3.0 by end of January 2017) > > > > > > Flink 1.4.0 by end of May 2017 > > > > > > Flink 1.5.0 by end of September 2017 > > > > > > Flink 1.6.0 by end of January 2018 > > > > > > I’ve put some more details including some pro’s and con’s into our > wiki. > > > The page is based on Kafka’s time-based release wiki page (Kafka also > > > recently started following a strictly time-based model) > > > > > > https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases > > > > > > > > > Once we’ve agreed on following that model, I’ll update the release plan > > > page accordingly: > > > https://cwiki.apache.org/confluence/display/FLINK/ > > > Flink+Release+and+Feature+Plan > > > > > > > > > Please let me know what you think about this idea! > > > > > > Regards, > > > > > > Robert > > > > > >
