>especially considering the benefit to all of having the master branch always >at a particular standard.
That is of no discussion. You are 100% right here. However, that statement is a bit sparse. What I mean is "a standard" could be to "test javadoc in CI only". Or even "skip checkstyle for default builds, and check that is CI". That would allow non-styled code to sneak into repository for a short time (yet the code is buildable), however it would dramatically reduce the build times for everyone => thus more time to write better code and tests. > I said that I would not put an “undue burden” on committers I do not ignore that. I'm just trying to understand how far are you pushing "put more burden" part of the equation. I do not like this one as it is a bit broad: Julian> But I would be inclined to put more burden on the committer Julian> committers need to use whatever tools are that their disposal If you mean "committers should use CI" here ^^^, that is perfectly fine for me. Julian> If the river is not clean it makes everyone’s life more difficult. Frankly speaking, I see no problems if "javadoc build" fails from time to time. Does "100% quality" indeed matters that much? An example how "pre-commit-testing saved the world" would help here to change my mind. On the other hand, we have recently used --amend to fix some things with a great success. Thus I treat 99.x% as "good enough". Just in case: there's a "performance river" (I do remember there's an issue I need to look into). I'm not sure if we can and/or need to keep it 100% safe (e.g. "no commit is allowed to degrade performance for no reason"). Well, instead of discussing things in theory, we could just vote to hear from others. Vladimir
