add more maintainers

[xuwei-k]

No description provided.

[rickynils]

I'm definitely interested in this.

These are some ideas I currently have, that are more or less related to maintenance:

• Create a scalacheck GitHub organization, to emphasize shared maintenance
• Keep the current ScalaCheck lib slim (or make it even slimmer) and dependency-less. Encourage utility libraries for specialized functionality/combinators/generators etc. This does not imply that the ScalaCheck core should stop evolve/improve.
• Improve the release process and versioning scheme. I have some ideas for making it more declarative, which should help maintainers releasing new versions.

I'm open for any kinds of comments and suggestions regarding project maintenance and maintainers. I don't have a lot of time for ScalaCheck work for the moment, but I'm willing to put in some time in order to achieve a better situation that will save both me and the general Scala community time in the future, and that will allow ScalaCheck to evolve further.

cc @non

[nrinaudo]

Not sure this is the right place to suggest this, but could one of these utility libraries you speak of be laws for Cogen, etc... to allow downstream libraries to more easily validate their implementstions?

An example is the enumeratum-scalacheck module that was published recently that basically copy / pasted tests defined here.

[ghost]

@rickynils I hope this suggestion does not pre-empt the way forward, but do you think it might be worth setting up the aforementioned GH organization, lest it is misappropriated?

[SethTisue]

this has come up again at #374. @etorreborre asked me for my take there, I guess as a representative of the Scala team at Lightbend?

for our own needs in the scala/scala repo, we can re-in-source, or fork, or whatever.

but for the community and ecosystem, there is also some renewed urgency now that Scala 2.13.0-M4, -M5, and -RC1 are all looming in the coming weeks and months.

making a scalacheck organization sounds right to me, and my guess is that if Rickard says he will authorize volunteer maintainers (and, more to the point for the 2.13 need, releasers) and asks them to step forward, they will.

[rickynils]

As you've all noticed, I have more or less gone offline for the last year. This is a temporary situation, and I very much like to keep ScalaCheck evolving. I do, however, wish for ScalaCheck to be less attached to me and more able to stand on its own (which is what this issue is about).

My immediate plan is to release the current master branch as 1.14.0 (#374), and to release any Scala milestone builds that is needed, but hopefully get a team of maintainers up and running (and able to make releases) for the releases after that.

I have created a scalacheck GitHub organization, and plan some sort of reach-out to find aspiring maintainers. Any feedback (comments, links to good articles etc) on how to proceed proceed from here is welcome.

[rickynils]

@Duhemm @sjrd @SethTisue @Philippus Do you think moving out the JS and Native versions of ScalaCheck to separate repositories (also hosted under the scalacheck org) is possible and desirable? In any case, I think we must find specific maintainers that are willing to keep those versions up to date with their runtimes.

[rickynils]

@nrinaudo Having various "laws" repositories with property definitions sounds like a good idea. If they are somewhat generic and/or widely used it would make sense to have such repos maintained by the scalacheck org. And I don't see a problem if there are current properties in the ScalaCheck "core" that could be moved to separate repositories, since they would just be test dependencies.

[sjrd]

Do you think moving out the JS and Native versions of ScalaCheck to separate repositories (also hosted under the scalacheck org) is possible and desirable? In any case, I think we must find specific maintainers that are willing to keep those versions up to date with their runtimes.

Possible? Yes. Desirable? It depends.

Separating the JS and Native variants in other repositories will definitely increase the sum total of effort required to maintain all the targets. It would probably reduce the effort to maintain the JVM target on its own, while creating some more effort in the separate repositories.

This means that if the same people are in charge of all those repositories, it definitely not desirable. It might be desirable if somehow this allows different people to maintain the different targets without interference between each other.

Note also that, at least for Scala.js, the current master (and now also 1.14.0) is fully ready to support all subsequent versions of Scala.js. Even when Scala.js 1.0.0-M4 comes out, the only thing that will be required would be for someone with publish access to perform:

$ git checkout v1.14.0
$ export PLATFORM=js
$ export SCALAJS_VERSION=1.0.0-M4
$ ./tools/travis-script.sh # to make sure everything passes
$ sbt js/clean js/publishSigned

No changes to the source tree should be required, similarly to publishing an old version for a new binary-incompatible version of Scala.

Given that, there should be nothing left to do in this repo to "keep those versions up to date with their runtimes". The Scala.js source compatibility until 1.0.0 final is pretty much frozen at this point.

[eed3si9n]

Adding more maintainers and giving them Sonatype OSS publishing rights sounds like a good start.

Not sure if they are aspiring, but off the top of my head, I nominate @xuwei-k (Kenji Yoshida, Scalaz maintainer) and @SethTisue (Lightbend Scala team). Both have vested interest in the upkeep of ScalaCheck, and are both responsible individuals.

As a stretch goal, implementing automated release via Travis CI upon tagging might be a good idea to lower the barrier for patch releases. (Might not work for oft-requested back-publishing against 2.13.0-Mx, so you still need human maintainers)

As per governance, you can make something up. Here is a strawman rules:

1. @rickynils is BDFL. He can override rules and votes.
2. Pull requests:
   2.a. Pull requests SHOULD have 7 days of review period.
   2.b. Pull requests SHOULD have 2 approvals by the maintainers.
   2.c. If 7 days pass since the first approval, it automatically goes through.
   2.d. Any one of the maintainers can require change request, or veto a pull request. (BDFL can veto the veto)
3. To release a new version, a maintainer opens an issue on GitHub "release 1.x.y", and requires additional 👍 by 1 other maintainer.

[Philippus]

I'm willing to help out where I can.

[SethTisue]

I’m happy to help with build and publish type stuff. (I’d likely be silent on anything more in the area of API design and so on.)

[SethTisue]

I think it’s fine to keep Scala.js and Scala Native in the same repo. Generally once the build stuff is set up it just works, and if we hit any trouble we JVM-centric folks don’t grasp there will be no shortage of eager volunteer help.

[rickynils]

From the comments above, I think we can decide on keeping JS and Native within the core repo.

[ghost]

Also willing to help out on the cross building side of things.

just fyi, I did the first cut of the scala.js implementation so have some idea of the internals - see 30e9cf2 and 6e369b8

[olafurpg]

👍 for @eed3si9n's suggestion.

I am happy to help configure the Travis CI to publish a Sonatype release on tag push. This involves

• exposing sonatype credentials as environment variable in master branch, but not PRs
• creating a fresh gpg private key that is only used for automated CI releases
• configuring .travis.yml to perform a sonatype release on tag pushes

I've done this multiple times for my own projects and it significantly lowers the complexity, esp. for projects with multiple maintainers.

[rickynils]

I just want to say that I'm very grateful for all offers to help out with maintaining ScalaCheck! As it looks now, I will not have time to start setting up the new organization until after the summer, when I'm back from paternity leave. I hope you'll bear with me. I will try my best at getting any urgent releases and builds out in the meantime.

[SethTisue]

@rickynils Scala 2.13.0-RC1 may be released in as soon as 2–3 weeks. I'd like to coordinate with you about making sure a ScalaCheck build for RC1 can be published reasonably soon afterwards (ideally, within a few days)

for RC1 specifically, a spectrum of possible solutions seems fine to me, including:

• you're confident you can commit to publish the release yourself in a timely fashion
• you grant one or more maintainers (could be someone from Typelevel you trust, or I could do it) minimal release powers for the RC1 timeframe only, so the release can happen without you, with the understanding that these new maintainers won't do anything else with their powers
• you grant broader powers to one or more new maintainers going forward

anything that allows a timely RC1 release to happen seems workable to me. it would be great to have the broader issue of this ticket resolved, but the desire for a broader solution needn't stand in the way of finding a narrower/temporary solution, either

[smarter]

Since the situation hasn't evolved in a while, I've opened a thread on contributors to discuss the maintenance of ScalaCheck: https://contributors.scala-lang.org/t/the-future-of-scalacheck-maintenance/3563, here's the main proposal I make there:

To unblock the situation, I propose that we move scalacheck to the scala organization on github, this is less work than creating a brand new organization, and it guarantees that at no point in the future will the situation be bottlenecked like this again. Concretely, either a Scala org admin (@SethTisue ?) need to give @rickynils the necessary rights to move scalacheck, or @rickynils needs to make a Scala admin maintainer so that they can move the repo themselves.

[SethTisue]

we have more maintainers now 🎉

you may have noticed that the repo is under the typelevel org now, which means that Typelevel admins can do admin stuff as needed.

the Java package name remains the same, the organization id of the artifacts on Maven Central remains the same as well

I'm not actually sure who has various powers now, I think it's something like:

• GitHub merge rights: @non @ashawley @djspiewak @SethTisue and ...?
• Sonatype publishing rights: afaik @non @djspiewak @ChristopherDavenport

thanks @rickynils for allowing and arranging this!