Dotty doc is getting repl checking similar to tut - as soon as I've cleared away other more pressing tasks.

We could make the tests depend on running a script to make sure scala-scala is cloned and updated, I did something similar when dottydoc had a Scala.js client.

What's the argument against dumping everything into /tests/scala-library?

I've argued in the past that this is what we eventually should do - I don't think the changes we're applying really have anything to do with improving, or making the old collections compatible with Dotty. Especially now that we are including the new collections in 2.13.

They're just a good set of integration tests IMO and should be moved to ./tests/old-scala-library 🎉

It can also be automated, you know ;)

@sjrd: omg, no more sbt magic please 😂

What's the argument against dumping everything into /tests/scala-library?

• not being able to upstream changes;
• not being able to merge changes from upstream to us;
• loosing commit history. I strongly believe that changing dotty directory structure wasn't worth it. I've lost around twice in productivity in everyday tasks;
• there's a huge amount of work involved in maintaining the library, for as long as we can I'd prefer to use one provided by Lightbend. Otherwise we'll spread our efforts thin.

That's a rare case when I'd prefer sbt magic to the alternative.

loosing commit history. I strongly believe that changing dotty directory structure wasn't worth it. I've lost around twice in productivity in everyday tasks;

Did the reorg break one of your tool in particular? The only change for me is that I have to remember to pass --follow to git log to get the full log.

I don't think we'll be upstreaming changes anyway as the new library is on its way in, and if so - it feels like the other arguments fall away.

We could still filter in the changes from the forked library, that would solve the problem of relevant history.

Clarification: I'm not proposing to include the scala-scala library as the dotty library, we'd not be maintaining it, it would simply be for integration tests and would reside in ./tests/old-scala-library

Did the reorg break one of your tool in particular? The only change for me is that I have to remember to pass --follow to git log to get the full log.

It broke both IntelliJ, github and SourceTree.

I don't think we'll be upstreaming changes anyway as the new library is on its way in

Note that standard library has more to it than standard collections. But that's true that collections represent >80% of it.

Note that standard library has more to it than standard collections.

That's true - but what else are we interested in compiling?

I think it'd be good to try to compile as much of scala-library as possible.

It broke both IntelliJ, github and SourceTree.

Indeed, I didn't notice github didn't --follow, they seem to be aware of the issue at least: isaacs/github#900

Mostly off-topic: https://chrome.google.com/webstore/detail/github-follow/agalokjhnhheienloigiaoohgmjdpned there's probably an alternative for FF too

According to the Internet, Sourcetree has a checkbox to enable follow, but they don't have a Linux version so I can't test it.

Well, the argument can still be made that this is non-obvious to contributors - we should document it.

• not being able to upstream changes;
• not being able to merge changes from upstream to us;

Have either of these ever append since the fork?

loosing commit history.

In the current situation if I want to understand history I have to manually correlate timestamps between two repos.

Also, I don't really see the value of commit history anterior to the fork point for tests file. If I make an analogy with any other library it sounds really silly: suppose I want to add parts of library L as pos tests for dotty, should I either:

1. Copy past stuff into tests/L (assuming the license allows it)

2. Require every contributor to clone a fork of L alongside lampepfl/dotty

?

Have either of these ever append since the fork?

No, but it's a bad thing on our side. There has been substantial improvements in Scala standard library over last 2 years.

If I make an analogy with any other library it sounds really silly:
suppose I want to add parts of library L as pos tests for dotty

Making an analogy here is wrong, this is the standard library which is our dependency. It isn't just a random test, it's part of out bootstrap. Unlike any other library\test it is also being actively developed.

Now that scala-scala became the scala2-library git submodule it will be downloaded with the rests as the documentation states to clone with git clone --recursive .... We also have documentation on updating an making change on the submodules.