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 > >> > >> > >
