flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Hogan <c...@greghogan.com>
Subject Re: [DISCUSS] What is a "Blocker" in our JIRA?
Date Fri, 05 May 2017 12:24:22 GMT
+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 <uce@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 <rmetzger@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 <aljoscha@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 <yuzhihong@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.kloudas@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 <rmetzger@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
>>>>> 
>>>>> 
>>> 
>>> 


Mime
View raw message