what to do with scala/scala PRs proposing standard-library additions/changes?

[SethTisue]

as per https://www.scala-lang.org/2019/12/18/road-to-scala-3.html , it's going to be a while before the standard library becomes open again for additions and binary-incompatible changes

what shall we do with the PRs at https://github.com/scala/scala/milestone/78 ? (nearly all of them are library PRs, not compiler PRs)

I'm tentatively thinking we should close all of them; linking to this issue in a comment; but leaving them on the 2.14.0-M1 milestone, so we can find them for possible resurrection someday

[julienrf]

I'm tentatively thinking we should close all of them; linking to this issue in a comment; but leaving them on the 2.14.0-M1 milestone, so we can find them for possible resurrection someday

I’m fine with this plan, but we should clearly explain that we don’t really “close” the PRs but we “delay” them.

Otherwise, we could create a separate repository (or branch, here?) with just the scala-library (like we did for the collections), so that we can merge all the PRs instead of delaying them. I’m not sure how easy it will be to re-merge everything upstream, eventually, though…

[NthPortal]

I have a lot of conflicting thoughts about what we should do.

on the one hand, the focus right now is on compatibility with Scala 3, and we don't want to take away effort from that by having lots of library PRs being created and needing attention. on the other hand, closing library PRs for a year is, to a degree, pushing away some (potential?) contributors. not everyone has the skills, desire, or comfort to contribute to the compiler (I have personally barely touched it). I'm also a bit concerned about library stagnation, but less so than the previous concerns.

as to whether or not it should get its own repository if we decide to keep accepting library PRs at this time, there are also advantages and disadvantages for each. having it as a branch in the main repo improves discoverability and is less confusing. on the other hand, having it in a separate repo means that PRs for the library are kept separate from compiler (and binary compatible library) PRs, making it easier to devote more attention to the "more important" PRs for compatibility with Scala 3. although I suspect there would end up being many confused people who open PRs on the main repo anyway, possibly making the separate repo more trouble than it's worth.

[SethTisue]

I have a lot of conflicting thoughts about what we should do

I see Dale has conflicting thumbs, too :-)

[dwijnand]

hehe

👍 for being explicit that "a closed PR doesn't mean a rejected PR"

👎 on a new branch or a new repo

I've actually been concerned for a little while that the project's evolution is too heavily biased to the language/compiler-side of things and, perhaps, not enough on the standard library, so I'm very sympathetic to what @NthPortal said.

Maybe we can kill two birds with one stone: would any of the regular library maintainers or contributors want to collaborate on the TASTY-based tooling necessary to unblock standard library changes in Scala 3.x?

Alternatively, would anyone like to help allow for more Scala 2.13 standard library changes by working on things like scala/bug#11804?

[SethTisue]

I closed all the open tickets on the 2.14.0-M1 tickets and (in most cases) added a link to this ticket, for context.

[SethTisue]

scala-collection-compat's scope has been widened to allow back ports of non-collections stuff, and we'll likely rename it to scala-library-compat

at scala/scala-collection-compat#317 we're weighing a further broadening of scope: perhaps we could also accept additions that would be moved to the standard library once that becomes possible again. in the meantime, people would be able to use them if they are willing to add the dependency

[smarter]

perhaps we could also accept additions that would be moved to the standard library once that becomes possible again.

I would have thought https://github.com/scala/scala-collection-contrib was the place for that.