+1 to restricting use of “blocker" -1 to post-hoc documentation and unreleased publication [0]
[0] http://www.apache.org/dev/release-publishing.html > On May 5, 2017, at 5:06 AM, Ufuk Celebi <u...@apache.org> wrote: > > 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 >>>>> >>>>> >>> >>>
