Am 2022-11-19 um 15:54 schrieb Oleg Kalnichevski:
On Sat, 2022-11-19 at 15:17 +0100, Michael Osipov wrote:
Am 2022-11-18 um 03:15 schrieb larry mccay:
Personally, I find RTC much more appropriate for mature-ish
projects where
quality and awareness are a higher priority than fast innovation.
I think the sub-topic here actually supports that notion.
Faster innovation and iterative development can happen in feature
branches
with appropriate merge criteria in place.
In Knox and other projects that I am involved with, trivial changes
don't
need review but with proper review, checkstyle integrations, etc, a
lot of
unnecessary thrashing can be avoided. While I don't have a binding
vote
here, I'd encourage you (from the sidelines) to codify your style
preferences in automated precommit checks and switch to an RTC
model.
These can actually be healthy growing pains.
(If you choose to see them that way) :)
I fully agree, this is actually what we do at Maven.
On the subject of the code style preferences. We do have a style check
plugin in place that enforces basic things like ASLv2 headers, white
spaces, trailing blanks, final variables and so on. It is very useful.
For many, many years I have been kindly and patiently asking several
individuals to stop making random style changes based on their personal
preferences and opinion about code aesthetics, phases of the Moon or
what not, unless they are backed and enforced by the style check
plugin. My requests have been routinely ignored. But as long as those
changes just made my personal life as a release manager harder I kept
my mouth shut.
Style is a constant battle. I don't like many styles including the one
from Codehaus or MAven, but I have accepted it because changing hundreds
of thousands lines of code does not make sense. If people aren#t willing
to fix although checkstyle complains we shouldn't accept the PR....
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
