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.

[SethTisue]

The differences are:

• scala-collection-contrib is 2.13-only (at present, anyway)
• scala-collection-contrib is an incubator — it's pretty wide open for things where it really isn't clear yet whether they will ultimately make stdlib. The bar is fairly low, it's a “sure let's take it and see what happens, see how users judge the quality to be, and how much demand from users there is”. The repo makes it easy for authors to get new collections things out to users on a trial basis, without those authors having to think about test infra and publishing and so forth themselves.
• scala-collection-contrib is an unlikely dependency for most projects, whereas scala-collection-compat is quite a likely dependency when crossbuilding.

Not saying we couldn't rethink all this, just saying what the differences are now.

[NthPortal]

personally, I'd prefer to keep scala-[collection|library]-compat scoped to compat, and have a different library scoped to future library stuff

[NthPortal]

now that I've thought about it some more, technically the compat library is a future library for 2.11 and 2.12. hmm...

[lrytz]

technically the compat library is a future library for 2.11 and 2.12

realizing this is exactly what brought up the idea (scala/scala-collection-compat#317 (comment))

[SethTisue]

https://github.com/scala/scala-library-next

[SethTisue]

the scala-library-next repo is now open for business

[SethTisue]

@lrytz recently asked about this over at scala/bug#12665

We don't have a clear story here, I'm afraid. There are a bunch of tickets in scala/bug on the 3.x milestone, and that's what I've done with 12665. There's library tickets in the scala/scala-library-next repo, but I haven't moved 12665 there since it isn't actionable in that repo.

I don't think they want such tickets in the lampepfl/dotty Issues tab since they're trying to keep that focused on bugs, but there's the Discussions tab, where all of the old dotty-feature-requests tab were relocated.

I have mixed feelings about the idea of relocating all the 3.x milestone tickets to the Dotty repo, since they will no longer turn up in a search of the scala org on GitHub. I really wish that lampepfl/dotty would get relocated to scala/scala3 or some such so we could easily search across both Scala 2 and 3 issues.

cc @ckipp01 who has been taking an interest in this sort of thing

[ckipp01]

I have mixed feelings about the idea of relocating all the 3.x milestone tickets to the Dotty repo, since they will no longer turn up in a search of the scala org on GitHub.

I echo the concern about discoverability. It was one of the main reasons I relocated the dotty-feature-requests to the actual Dotty repo. My hope is that pros of discoverability there will outweigh any of the cons. For any potential or even at times current contributors to the let's call it core compiler/stdlib ecosystem, it's very difficult to get a grip on where all the various repos are. When I was first digging in it annoyed me enough that I created this guide for myself, which I now realize is out of date and missing some Scala 2 repos.

I really wish that lampepfl/dotty would get relocated to scala/scala3 or some such so we could easily search across both Scala 2 and 3 issues.

I've heard this from multiple people working in the ecosystem and I've also first hand seen how confusing it is for people that aren't daily working on the compilers. I have yet to hear a convincing argument as to why this isn't the plan. I've personally had to answer this question dozens and dozens of times to people asking where the Scala3 codebase is since they can't find it under the... Scala Org. I may actually create a discussion on this in the Dotty repo to have a single place I can link to when people ask about it, and hopefully whatever the reason for not moving it can be kept there as well.

Again, I don't have a ton to add to the conversation apart from the fact that I think collectively we can do a better job at centralizing things for better discoverability. If there are ideas on how to achieve this, I'm happy to put in some work on it.

EDIT: I created scala/scala3#17965 to discuss this.

[bjornregnell]

I completely agree! Every time I've been away from issues for some weeks I forget were things are scattered and sometimes have difficulties in remembering where to look. It would be marvelous if all threads were discoverable from the https://github.com/scala/ org.

[SethTisue]

Lukas has added a "library:next" label to the scala/scala repo, so when closing a library-addition PR we can add that label, to help find the PR later when things open up again: https://github.com/scala/scala/pulls?q=is%3Apr+sort%3Aupdated-desc+label%3Alibrary%3Anext+is%3Aclosed

We did not do a sweep through all old closed PRs, but we'll try to remember to add the label when we happen across eligible PRs.