Thank you, Jacek, for starting the thread; those things are essential for
developer productivity.
I support the idea of opting out vs opting into checks. In my experience,
it also makes things easier and faster during review time.
If people have to opt-in - it is one more thing for new people to
Hi everyone,
Due to unforeseen circumstances, the Zoom link for this week’s Apache
Cassandra Contributor Meeting has changed. The calendar event and the
Confluence page have been updated with the new link:
https://us02web.zoom.us/j/81043384800?pwd=K240K2JSR0I4N05GTHN3cXRiVzMvZz09 -
if you are atte
Yes, in this case, opting-out is better than opting-in. I feel like the build
process is quite versatile and one just picks what is necessary. I never build
docs, there is a flag for that. I turned off checkstyle because I was fed up
with that until Berenguer cached it and now I get ant jar with
> not running it automatically with the targets which devs usually run locally.
The checks tend to have an opt-out, such as -Dno-checkstyle=true… so its really
easy to setup your local environment to opt out what you do not care about… I
feel we should force people to opt-out rather than opt-in…
Hello,
I want to discuss the possibilities of fixing CASSANDRA-18591 and
CASSANDRA-18589 (~exceptions during reads), considering that TCM will
become a reality soon.
While both issues can be hit even on a single-node cluster, I think it's
important for the solution to be at least TCM-friendly and
That would work as well Brandon, basically what is proposed in
CASSANDRA-18618, that is "check" target, actually needs to build the
project to perform some verifications - I suppose running "ant check"
should be sufficient.
- - -- --- - -
Jacek Lewandowski
pon., 26 cze 2
The "artifacts" task is not quite the same since it builds other things
like docs, which significantly contributes to longer build time. I don't
see why we couldn't add a new task that preserves the old behavior though,
"fulljar" or something like that.
Kind Regards,
Brandon
On Mon, Jun 26, 202
Berenguer, as I said, I started this discussion because it is confusing
that we do implicit and unexpected tasks.
It is inconsistent that we run checkstyle, but we skip static code analysis
like Eclipse-Warnings because that actually falsifies the advantages of
running checks automatically.
More ro
Hello everyone,
We can replace RAT with the appropriate checkstyle rule - the HeaderCheck,
I think. This will reduce the number of tools we now use and reduce the
build time as only modified files will be checked, and this, in turn, will
remove some of the concerns mentioned in the first message.
Just for awareness if you rebase thanks to CASSANDRA-18588 checkstyle
shouldn't be a problem anymore. If it is still let me know and I can
look into it.
On 26/6/23 13:11, Jacek Lewandowski wrote:
Yes, I've mentioned that there is a property we can set to skip
checkstyle.
Currently such a goa
Yes, I've mentioned that there is a property we can set to skip checkstyle.
Currently such a goal is "artifacts" which basically validates everything.
- - -- --- - -
Jacek Lewandowski
pon., 26 cze 2023 o 13:09 Mike Adamson napisał(a):
> While I like the idea of this
While I like the idea of this because of added time these checks take, I
was under the impression that checkstyle (at least) can be disabled with a
flag.
If we did do this, would it make sense to have a "release" or "commit"
target (or some other name) that ran a full build with all checks that c
Just for completeness the change is a handful loc. The rest is added
tests and we'd loose the sstable format change opportunity window.
Thx again for the replies.
On 26/6/23 9:33, Benedict wrote:
I would prefer we not plan on two distinct changes to this,
particularly when neither change is pa
I would prefer sthg that is totally transparent to me and not add one
more step I have to remember. Just to push/run CI to find out I missed
it and rinse and repeat... With the recent fix to checkstyle I am happy
as things stand atm. My 2cts
On 26/6/23 8:43, Jacek Lewandowski wrote:
Hi,
Th
I would prefer we not plan on two distinct changes to this, particularly when neither change is particularly more complex than the other. There is a modest cost to maintenance from changing this multiple times. But if others feel strongly otherwise I won’t stand in the way.On 26 Jun 2023, at 05:49,
15 matches
Mail list logo
