Mailing List Archive

Hi Robert,

> * gradle check -x test: 8 minutes, 15 seconds
> * gradle test: 9 minutes, 8 seconds

These are done in parallel on separate VMs - if we merge them the
combined time will be longer (that's why I split them into two
stages).

> * lift: 84 minutes

This is some sonatype static checker/ bot. I don't know who added it
but it doesn't seem to be harmful?

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

On Sun, Nov 28, 2021 at 11:34 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>
> Hi Robert,
>
> > * gradle check -x test: 8 minutes, 15 seconds
> > * gradle test: 9 minutes, 8 seconds
>
> These are done in parallel on separate VMs - if we merge them the
> combined time will be longer (that's why I split them into two
> stages).

OK, I see. I was thinking that a simple 'gradle check' as the github
action would be easier to understand / reproduce locally for
contributors, and that by combining the two tasks into one, we'd use
less server-side resources (I have no idea what the limits are here,
etc).

>
> > * lift: 84 minutes
>
> This is some sonatype static checker/ bot. I don't know who added it
> but it doesn't seem to be harmful?

The main thing I don't like is the long latency (more than an hour)
before a PR goes "green" or "red". I have a habit to generally not
even look at PRs until I see the green checkmark, I try to encourage
this workflow at work. General idea: don't waste humans time if the
computer can do it.

The second thing I don't like is that this static checker doesn't run
locally. So if the user did the right thing and ran 'gradle check'
before creating their PR, they could still fail it? Without any way to
test changes locally to make the thing pass, just play whack-a-mole?
Again, I'm not sure what it does, but I kinda don't like that
workflow.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

> OK, I see. I was thinking that a simple 'gradle check' as the github
> action would be easier to understand / reproduce locally for
> contributors, and that by combining the two tasks into one, we'd use
> less server-side resources (I have no idea what the limits are here,

It does use more resources - true. If this is a problem - we can go
back to just 'check.
It is now currently split into two phases but functionally equivalent
to 'gradlew check' -
it just runs the non-test checks first (linters). I don't mind if it's
done in one stage (but it will be longer).

> The main thing I don't like is the long latency (more than an hour)
> before a PR goes "green" or "red". I have a habit to generally not

I really know zero about this plugin. I don't even think it causes an
error, even if it "fails". It just adds comments about unsafe code, I
think?... The few times it did comment on my PRs it was mostly wrong -
I didn't look at its output again.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

On Sun, Nov 28, 2021 at 12:37 PM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>
> > OK, I see. I was thinking that a simple 'gradle check' as the github
> > action would be easier to understand / reproduce locally for
> > contributors, and that by combining the two tasks into one, we'd use
> > less server-side resources (I have no idea what the limits are here,
>
> It does use more resources - true. If this is a problem - we can go
> back to just 'check.
> It is now currently split into two phases but functionally equivalent
> to 'gradlew check' -
> it just runs the non-test checks first (linters). I don't mind if it's
> done in one stage (but it will be longer).
>
> > The main thing I don't like is the long latency (more than an hour)
> > before a PR goes "green" or "red". I have a habit to generally not
>
> I really know zero about this plugin. I don't even think it causes an
> error, even if it "fails". It just adds comments about unsafe code, I
> think?... The few times it did comment on my PRs it was mostly wrong -
> I didn't look at its output again.
>

Yeah, to me the current situation is confusing. Splitting the two
check tasks to "optimize for latency" doesn't make sense when you are
still going to wait 90 minutes on the very slow third check that none
of us understand :)

Personally, I'd prefer that users see one automated PR check, and that
it's "gradle check", very easy for them to run locally. Obviously, we
can and should do things to keep this running fast!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Hi,

> > OK, I see. I was thinking that a simple 'gradle check' as the github
> > action would be easier to understand / reproduce locally for
> > contributors, and that by combining the two tasks into one, we'd use
> > less server-side resources (I have no idea what the limits are here,
>
> It does use more resources - true. If this is a problem - we can go
> back to just 'check.
> It is now currently split into two phases but functionally equivalent
> to 'gradlew check' -
> it just runs the non-test checks first (linters). I don't mind if it's
> done in one stage (but it will be longer).
>
> > The main thing I don't like is the long latency (more than an hour)
> > before a PR goes "green" or "red". I have a habit to generally not
>
> I really know zero about this plugin. I don't even think it causes an
> error, even if it "fails". It just adds comments about unsafe code, I
> think?... The few times it did comment on my PRs it was mostly wrong -
> I didn't look at its output again.

I can give a bit more information. This plugin is provided by Sonatype ("Sonatype Lift") and is some code quality checker. Previously it was called "musebot" (before Sonatype aquired the original company).

You can get more history about it on the ASF Slack Channel (https://the-asf.slack.com/archives/C01B33Z4KSA) where some people from Muse / Sonatype and ASF Infra are chatting. Apache Solr was one of the first projects where it was enabled (on old repository). You can see this also in the marketing pages: https://lift.sonatype.com/getting-started (see screenshot).

Personally said, in my experience this bot always created false positives (similar like those horrible dependency check bots always identifying icu4c in our dependencies, although we use icu4j), so I think it is obsolete. The original MUSE personnel was always responsive (when it was called musebot) and they fixed those errors - but since it was aquired by Sonatype it is dead, just some marketing tool!

Lucene (and also Solr) have so cool checks in their build system which run fast, there's no need for this bot. This is only marketing for Sonatype and I don't think we should do this. A bot that has so few resources so it takes 90 minutes to run and only producing false positives is bad for us and also Sonatype. So stop this marketing!

We should open issue on INFRA issue tracker and ask to disable it for apache/lucene, apache/lucene-solr and maybe also apache/solr (but the latter should be decided by the Solr mailing list).

Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org