Thanks for this discussion Robert. I agree with your points. +1 Regarding the documentation: I also agree with Kostas and others that it is very important to have good documentation in place. The good thing about our current doc deployment model is that we can update the docs for a released version even after it has been released. Yes, ideally, we would have the docs already in place when we release and only do small updates (doc "bug fixes"), but I don't see that happening in the near future. Therefore, I would unblock the documentation issues as well for now. Maybe this is a point that we can revisit in the near future. All in all, I think that the docs have made tremendous progress in the last 6 months. :-)
– Ufuk On Fri, May 5, 2017 at 9:47 AM, Robert Metzger <rmetz...@apache.org> wrote: > I understand the motivation to make documentation equally important as bugs > in software, but from my point of view as a release manager, its not easy > to keep track of the release status when some blockers are not real > blockers (I can't just look at the number in JIRA, but I have to manually > go through the list and read every JIRA to get the real number of release > blockers) > > As I've said in my initial email, a blocker is an issue in the code where > no workaround exist and the system is virtually unusable. Missing > documentation is always something users can work around. > > I agree with Ted that we can still merge documentation changes while > testing RC0. > > On Fri, May 5, 2017 at 7:48 AM, Aljoscha Krettek <aljos...@apache.org> > wrote: > >> IMHO, the problem with the “add documentation” issues is that they should >> ideally have been documented as part of the feature development. (Full >> disclosure: I’m not innocent there and the Per-Key Window State Doc is >> somewhat my fault.) Sometimes, though, several features are developed over >> the course of multiple Jiras and it only makes sense to document the final >> new state. >> >> Best, >> Aljoscha >> > On 4. May 2017, at 20:07, Ted Yu <yuzhih...@gmail.com> wrote: >> > >> > I agree with Kostas. >> > >> > Considering 1.3 has many new features which need non-trivial effort for >> > testing, maybe the work on documentation can be done in parallel to >> testing >> > RC0. >> > >> > Cheers >> > >> > On Thu, May 4, 2017 at 10:54 AM, Kostas Kloudas < >> k.klou...@data-artisans.com >> >> wrote: >> > >> >> Hi Robert, >> >> >> >> Thanks for clarifying this so that we all have a common definition of >> >> what is a blocker. >> >> >> >> The only thing I would disagree, and only is some cases, is the >> >> documentation part. >> >> I think that in some cases, things that have to do with documentation >> can >> >> and >> >> should become blockers. Mainly to motivate devs to take care of them. >> >> >> >> There are important parts of Flink which are not (sufficiently or at >> all) >> >> documented >> >> and this can result in confusion / load in the mailing list / wrong user >> >> assumptions. >> >> >> >> Regards, >> >> Kostas >> >> >> >> >> >>> On May 4, 2017, at 7:38 PM, Robert Metzger <rmetz...@apache.org> >> wrote: >> >>> >> >>> Hi Flink Devs, >> >>> >> >>> while checking our JIRA for the 1.3 release, I found that some issues >> of >> >>> type "New Feature" have the priority "Blocker". >> >>> With the time-based release model, I don't think its possible to mark a >> >> new >> >>> feature as a blocker. >> >>> >> >>> Only a bug that leads to wrong results, system failure or completely >> >>> undefined behavior (without any available workaround) is a blocker. >> >>> New features, missing documentation or inconveniences are never >> blockers. >> >>> >> >>> I understand that people want to express that their feature is so >> >> important >> >>> that it is basically blocking us from creating a release, but with the >> >>> time-based release model, this doesn't really apply. >> >>> >> >>> If nobody disagrees, I'll un"block" new features to "Major" new >> features. >> >>> >> >>> >> >>> Regards, >> >>> Robert >> >>> >> >>> >> >>> Examples: >> >>> https://issues.apache.org/jira/browse/FLINK-6198 >> >>> https://issues.apache.org/jira/browse/FLINK-6178 >> >>> https://issues.apache.org/jira/browse/FLINK-6163 >> >>> https://issues.apache.org/jira/browse/FLINK-6047 >> >>> https://issues.apache.org/jira/browse/FLINK-5978 >> >>> https://issues.apache.org/jira/browse/FLINK-5968 >> >> >> >> >> >>
