Backport "Support src filter in -WConf (Closes #17635) (#18783)"

[mkurz]

Backports

• Support src filter in -WConf (Closes #17635) #18783 (commit: 86e2fe5)

for next 3.3.4 release.

Besides import conflicts cherry-picking was smooth.

[mkurz]

Any chance someone looks at this PR or assign the 3.3.4 milestone? Thanks!

[SethTisue]

Just chiming in to say that I think this would be highly beneficial to see merged for 3.3.4. Beneficial in general, but also specifically for our needs at Lightbend. (And of course @mkurz represents Play, obviously important users of Scala.)

There doesn't seem to be a 3.3.4 milestone I can assign. I'll take the liberty — which I try not to take too often! — of mentioning @Gedochao and @Kordyjan because I'd like to understand what the intended workflow is here. Like, is the target branch being release-3.3.4 sufficient for the PR to be noticed when 3.3.4 is put together? Or is there some label I could apply in a case like this? I thought about "backport:nominated" but it doesn't seem exactly apropos since this PR actually is a backport 😄

[SethTisue]

There was some discussion at core meeting today about LTS backports (cc @sjrd, who raised it). Some points:

1. The team is aware there is a lack of public documentation about the intended workflow and they aim to improve it (but I'm not sure when, and @Kordyjan is currently less available than usual).
2. The workflow involves mass backporting of many PRs at once, in chronological order to help keep the merge conflict situation from becoming unwieldy.
3. Therefore, individual backport PRs like this one are (though obviously well intentioned, of course — thank you!) aren't as helpful as one might think and probably won't be merged.

[joroKr21]

Therefore, individual backport PRs like this one are (though obviously well intentioned, of course — thank you!) aren't as helpful as one might think and probably won't be merged.

Is there some way to mark a PR as a backport candidate?

[sjrd]

All PRs are automatically backport candidates. ;)

[maslovalex]

even taking in account

Therefore, individual backport PRs like this one are (though obviously well intentioned, of course — thank you!) aren't as helpful as one might think and probably won't be merged.

Shouldn't this be targeting lts-3.3 branch ?

[WojciechMazur]

Thank you for your efforts in backporting this to the LTS. However, we've decided to go with alternative backport in #21087 - our procedure is mostly based on dedicated project and scripts used to ease decisions and cherry-picks into the LTS. One of dependencies of backported changes #18503 was not previously backported to the LTS (to be decided if change in semantics is acceptable on the next core meeting) which lead to failures in the CI. I've decided it would be easier to resolve conflicts (especially after rebase from invalid branch release-3.3.4 to lts-3.3) in a fresh branch.

[SethTisue]

#18503 was not previously backported to the LTS (to be decided if change in semantics is acceptable on the next core meeting

I don't remember whether that core meeting discussion took place, but in any case, it seems reasonable not to change the behavior in a patch release