Migrating lampepfl/dotty to scala/scala3

Hi contributors,

With Scala 3 being released (:tada:) we want to consolidate our GitHub setup, specifically in terms of transferring and renaming https://github.com/lampepfl/dotty to https://github.com/scala/scala3. We also intend to rename scala/scala to scala/scala2, but there’s no urgency so we’ll do that in a few months. For the scala/scala3 migration, we want to avoid it impacting any imminent patch releases, i.e. 3.0.1, so our paper-napkin plan is the following:

  1. release 3.0.1-RC1, this week or next
  2. after 6 weeks release 3.0.1
  3. transfer and then rename the repo, and fix all the scripts/config

Which roughly puts us in the week of 5 July. By the way, the reason we can’t “just” move scala/scala to scala/scala2 and move the new repo into scala/scala is that it would break every existing URL to scala/scala.

From https://stackoverflow.com/a/63876266/463761 it looks like the order of operations doesn’t matter.

We haven’t talked about https://github.com/scala/bug yet, I think that could be renamed to scala2-bug, and scala/scala-dev to scala/scala2-dev. https://github.com/lampepfl/dotty-feature-requests probably should become scala/scala3-feature-requests, but there’s also the possibility of switching to a “Feature Requests” or “Ideas” category in https://github.com/lampepfl/dotty/discussions/categories

Let us know if you have any thoughts or concerns on this plan.

Thanks,
Dale

9 Likes

I’m not really sure you can, but what about renaming the scala/scala repo to scala/2, lampepfl/dotty to scala/3, scala/bug to scala/2-bug and similar for whatever else should be renamed?

Thats an interesting idea. It turns out you can create a repo called “2”, but I still don’t think we should do it because that would be the default name when users clone or fork the repo.

2 Likes

Isn’t there a field for the fork name? I guess you would have to remember, but even if you don’t you just notice later and rename the repo. Not ideal, but scala/scala2 looks like an useless repetition

The only thing I would advice against would be using GitHub Discussions for feature requests. I’ve experimented with it quite a bit and it’s currently not suitable (no way to close requests or turn them into issues is the first major blocker for me).

As for the rest, scala/2 would be strange since git clone would produce a directory named 2. I’m fine with the repetition, and we already lived with it with scala/scala so no big deal there

9 Likes

I’d have suggested scala/ there, but blank names obviously aren’t allowed.

1 Like

Why not keep scala/scala for Scala 2, but rename the current main branch to 2.x? (and then move lampepfl/dotty into the main branch of scala/scala)

I guess the main issue is that unlike if we transferred lampepfl/dotty to scala/scala, there will be no automatic redirect from the former to the latter.

4 Likes

That can be fixed by keeping the 2.x branch called main and just set the main repo branch to 3.x, so new links go there and old ones pointing to main still go to 2.x

However this would potentially favor Scala 2 over Scala 3, idk

  • RubenVerg :heart:

scala/scala hasn’t had a main/master branch for ages. It has 2.11.x, 2.12.x and 2.13.x. That said, the real problem with this approach is migrating the issues and PRs.

3 Likes

You can’t search multiple branches on Github, so I’d prefer the repos to stay seperate

3 Likes

scala/bug contains many useful discussion about the evolution of the Scala language. Assuming that eventually everyone migrates to Scala 3.x in some time (it’s been two years since 2.13 came out), I think Scala 3.x should also inherit scala/bug.

  1. Create a new repository scala/scala2-bug.
  2. Transfer dotty issues into scala/bug programmatically.
  3. Close fixed-in-Dotty issues in scala/bug, or transfer to scala/scala2-bug.

Pro:

  • Monotonically increasing numbering scheme Scala bugs that’s been going on since JIRA days.
  • Prevents bug bankruptcy of 1805 open issues.
1 Like

I don’t disagree, but it’s too late: dotty started it’s own count.

1 Like

It makes sense that Dotty had its own list of bugs during the development phase; now that it’s called Scala 3, we can transfer all the issues if all parties agree?

1 Like

They should be transferred when you first move the scala-2 branches into lampepfl/dotty, then move scala/scala to scala/scala2-old, and finally move lampepfl/dotty to scala/scala.

(Then, scala/scala2-old may be archived.)

Then, we get the following benefits:

  • scala-3 is the scala, so it resides at scala/scala
  • all links to lampepfl/dotty are redirected
  • all links to scala/scala code still work (because they contain the branch name 2.13.x or alike)
  • all scala-3-issues and PRs are at scala/scala
  • all scala-2-issues are still at scala/bug (which may be moved to scala/scala2-bug)
  • all scala-2-PRs are archived (the ~15 open ones could be transferred manually)
  • everything is in one repo. When looking for “scala”, there is no “Oh, that’s in the other scala repo”

Disadvantages:

  • links to scala-2 PRs (scala/scala/pull) will break (and not be redirected to scala/scala2-old/pull)
  • everything is in one repo. As @Katrix pointed out this is hard to search within Github

Disclaimer: I assume it works like that, but we schould definitively test it beforehand :smiley:

s/seperate/separate, the mnemonic is “pare” as in “paring knife”.

s/it's/its where “its own count” is like “his own count”.

s/scala2-old/scala-mature I think I already joked about not being ageist, and yes that is the spelling, as I learned.

it’s been two years since 2.13 came out

Let’s agree that pandemic year does not count.

I agree that if Scala 3 is the new normal, then folks should visit scala/scala to report bugs and contribute.

After listening to Odersky’s keynote on how Scala 3 came about, I also wish it had been developed on a branch. I also wish they hadn’t ditched partest just when it got better. I still can’t contribute a Scala 3 test without researching how. That is, there is a lot to say in favor of so-called synergy. Is that still a word?

1 Like

Sorry for reviving this thread, just wanted to ask - is this still happening?

Not sure about the semantics of “still”, but currently, the github repos have not changed for either PRs or new tickets.

We’ll do it eventually, but it is quite a large effort to migrate and adapt everyone’s work flow to the new system. We have to weigh convenience of having one repo against loss of productivity for some protracted amount of time for the people who fix the bugs today. My personal take is that we should undertake it once we have enough trained people to stay atop the open issues queue.

6 Likes