Hi everyone,
thanks for discussing this and providing your input.
Here's a summary of what I got out of your responses:
* There are already process and template in place, which isn't really executed.
* Just adjusting the process or the template won't help.
* Opening PRs shouldn't become more dif
> * 187 contain "yes / no / don't know" and thus have not answered at least
one of the questions
I think there are quite some PRs that highlight in bold the answer to this
question while keeping all options there. I'm all in favour of replacing
this with a checkbox.
On Thu, 25 Nov 2021 at 10:47
Hi Till,
> * I agree with Ingo that the "Verifying this change" section can be
> cumbersome to fill in. On the other hand it reminds contributors to verify
> that his/her changes are covered by tests. Therefore, I would keep it.
IMO it could be replaced with a checkbox "I have made sure all chang
When I started writing this response I thought that the current PR template
is mostly ignored by the community. In order to verify this I went through
the first two pages of open PRs and I was very positively surprised that
almost all PRs filled out the current template. Hence, I had to redact my
o
I also like the checklist provided by our current PR template. One annoying
thing in my opinion, though, is that we do not rely on checkboxes. Ingo
already proposed such a change in [1]. Chesnay had some good points on
certain items that were meant to be added to the template but are actually
alrea
Hi Joe,
Thanks for bringing this to our attention.
In general, I agreed with Chesnay's reply on PR [1]. For the rule-3, we might
indeed create another PR to add documentation previously. And I think if
forcing to obey it to include the documentation in the same PR, that could
benefit the revie
> On the other hand I am a silent fan of the current PR template because
> it also provides a summary of the PR to make it easier for committers
> to determine the impacts.
I 100% agree that part of a PR (and thus the template) should be the
summary of the what, why, and how of the changes. I also
Hi all,
Maybe I am the devil's advocate but I see the stability of master and
the definition of done as disjunct properties. I think it is more a
question of prioritization that test instabilities are treated as
critical tickets and have to be addressed before continuing any other
work. It will al
Hi all,
Thanks for bringing this up for this discussion, because I think it's an
important aspect.
>From my perspective, a 'definition of done' serves two purposes:
1. It informs the contributor on what's expected when making a contribution
in the form of a PR
2. It instructs the committer on wha
+1 with Ingo proposal, the goal of the template should be to help developer
to do a self check of his/her PR quality, not to define whether something
is done or not. It's up to the committer to check that the "definition of
done" is fulfilled.
> The Definition of Done as suggested:
This checklist
Hi Joe,
thank you for starting this discussion. Having a common agreement on what
to expect from a PR for it to be merged is very much a worthwhile goal.
I'm slightly worried about the addition to the PR template. We shouldn't
make opening PRs even more difficult (unless it adds sufficient benefi
Hi Joe,
Thanks for starting this thread! It seems the proposal emphasizes
documentation and test coverage, which are normal practices in
releasing a large software.
It looks all good but the point is that how you'd like to apply it?
We have a checklist in the PR template and @flinkbot will toast
Dear Flink Community,
We as the release managers of the 1.15 release are suggesting to introduce a
“Definition of Done".
Let me elaborate a bit on the reasons:
* During the release process for 1.14 the stability of master was sometimes in
a state that made contributing to Apache Flink a bad exp
13 matches
Mail list logo
