@Arvid Pretty sure that goes against ASF rules.
On 19/02/2020 14:26, Arvid Heise wrote:
Let me be a troll, but couldn't we just disable push to master for
committers?
That would make smaller backports harder, but it would also eliminate
unreviewed commits. And we wouldn't need to draw a line be
Let me be a troll, but couldn't we just disable push to master for
committers?
That would make smaller backports harder, but it would also eliminate
unreviewed commits. And we wouldn't need to draw a line between minor for
direct push and bigger changes that need review.
On Wed, Feb 19, 2020 at 1
Hi,
I agree with question posted by Till, what problems are we trying to solve?
Regarding merging unreviewed commits, I’m +1 for disallowing those things.
Anything that is trivial enough that I would accept as being merged without
review, is also trivial enough to review. The additional review
Side comment: the problem of not knowing where a commit came from could
be fixed by always including merge commits, just saying... ;-)
Aljoscha
On 19.02.20 11:43, Robert Metzger wrote:
Thank you for your response. Your response makes me realize that I should
have first asked whether other comm
Thank you for your response. Your response makes me realize that I should
have first asked whether other committers consider the amount of hotfix
commits problematic or not.
>From the number of responses to my message, I have the feeling that most
committers are not concerned.
I personally believe
Thanks for raising this point Robert. I think it is important to remind the
community about the agreed practices once in a while.
In most of the cases I had the impression that the majority of the
community sticks to the agreed rules. W/o more detailed numbers (how many
of the hotfix commits are o
Hi all,
I would like to revive this very old thread on the topic of "unreviewed
hotfixes on master" again.
Out of the 35 commits listed on the latest commits page on GitHub, 18 have
the tag "hotfix", on the next page it is 9, then 16, 17, ...
In the last 140 commits, 42% were hotfixes.
For the sa
Hi all,
in principle I agree with Max. I personally avoid hotfixes and always open
a PR, even for javadoc improvements.
I believe the main problem is that we don't have a clear definition of what
constitutes a "hotfix". Ideally, even cosmetic changes and documentation
should be reviewed; I've see
Max,
I certainly agree that hotfixes are not ideal for large refactorings and
new features. Some thoughts ...
A hotfix should be maven verified, as should a rebased PR. Travis is often
backed up for half a day or more.
Is our Jira and PR process sufficiently agile to handle these hotfixes?
Will
I fully agree with Max, it just enables people to be sloppy and/or lazy
without providing
any good means of quality control.
On 27.05.2016 12:10, Maximilian Michels wrote:
Hi Flinksters,
I'd like to address an issue that has been concerning me for a while.
In the Flink community we like to pus
10 matches
Mail list logo
