More maintainers?

[kailuowang]

Hi there! I am just curious if Scanamo can use more maintainers. I myself would love the honor to help with maintenance like release and build as well as PR review. I have extensive experience in maintaining Scala OSS projects. Scanamo has been critical to most of my projects in production. Please let me know if I can help. Thanks so much!

[regiskuckaertz]

@kailuowang I know your work sir and it would be a real pleasure to welcome you in the team, esp. as I don't intend on contributing much anytime soon. This is me on the outside

but on the inside

cc @mchv @rtyley @davidfurey

[rtyley]

Hi @kailuowang ! Similarly, I know (and depend on!) your work, and would be delighted to welcome you to as a maintainer of Scanamo! While we're doing that, it might be a good idea to talk about what all us maintainers are hoping to get out of Scanamo, aims for the project, etc so we can all support each other.

What I'm going to say broadly reflects the needs of us at the Guardian (at least, I think so - David/Mariot feel free to correct me!). As you might know, Scanamo was initially created by Phil Wills while he was at the Guardian, and all the current GitHub owners of this org are either currently working at the Guardian (@davidfurey @rtyley @mchv) or are former Guardian staff (@regiskuckaertz). The Guardian currently has ~50 repos that depend on Scanamo, many of which are active - we need to maintain those projects, and part of that is keeping our dependencies up-to-date with security patches, system updates etc - we don't want to get left behind and stuck on old versions! The current core functionality of Scanamo is fantastic for us, and we don't have any current pressing needs to extend it's functionality (other than keeping up to date with new AWS DynamoDB features that are useful) - we just need it to stay up-to-date and to be able to fix bugs that affect us.

For us at the Guardian, and particularly for myself, we would like:

• To ensure Scanamo supports the latest Scala language versions, with a migration path from one to the next - at the moment, my target for that support would be Scala 3 & 2.13.
• To minimise Scanamo maintenance load. We can do this by eg:
  • Dropping older Scala language versions as they begin to take significant development effort to support. So, I'd personally be happy to sacrifice Scala 2.12 support soon, if it were to make the transition to Scala 3 easier.
  • Avoiding increasing the size/complexity of the project
• Stability of Scanamo API/syntax - with so many existing projects depending on Scanamo at the Guardian, upgrades can be quite a substantial effort if syntax changes are required. This is also a bit exacerbated because the versioning scheme for Scanamo has been simple increments of milestone number for several years - if we were to bite the bullet and get to 1.0.0 we could perhaps agree to semver-style updates, with Minor/Patch level updates not requiring syntax changes in projects that use Scanamo.

So that just reflects what we at the Guardian need, and obviously you @kailuowang at your own company might have different needs which it would be great to understand, so please do let us know how the above fits in with what you'd like to contribute, and what you're going to need?

Would it be good to have a video hangout sometime in the coming week to say hi?!

[kailuowang]

Hey, @rtyley Thanks very much for the detailed information. It seems that what you guys from Guardian need from Scanamo is exactly what I need as well. Our goals for Scanamo are perfectly aligned.
The 3 things I think I would propose is that

1. release M16
2. migrate away from Travis to Github action.
3. I think Scanamo core is ready to go 1.0.0. With the current mono-repo setup, those 3rd party integration modules are sharing the same version with the core, which means that we're tieing 3rd party major version to Scanamo's. So at some point, we might need to break them into separate repos. It could be when one of the dependencies breaks binary compatibility, or before we release 1.0.0. I have no preference over one way or another.

I'll be more than happy to video hangout in the coming week.

[rtyley]

Our goals for Scanamo are perfectly aligned.

That's great! 😄

The 3 things I think I would propose is that

1. release M16

I actually did that yesterday! It was my first time performing a release of Scanamo, but it's actually a remarkably easy process - just push a git tag and the CI takes care of releasing it - it's available on Maven Central now.

2. migrate away from Travis to Github action.

I've not quite had enough time to learn the advantages of GitHub Actions over Travis, but I have noticed that properly configured GitHub Actions seem to build faster! What are your favourite advantages? There'll be a few secret-values to transfer over - and we might want to consider whether we want to proceed with using @regiskuckaertzs credentials!

3. I think Scanamo core is ready to go 1.0.0. With the current mono-repo setup, those 3rd party integration modules are sharing the same version with the core, which means that we're tieing 3rd party major version to Scanamo's. So at some point, we might need to break them into separate repos. It could be when one of the dependencies breaks binary compatibility, or before we release 1.0.0. I have no preference over one way or another.

Yeah, I'm happy enough to for them to leave them be for now.

I'll be more than happy to video hangout in the coming week.

Would a quick 20 minute call on Tuesday be good? I can do anytime within 8:30am-10am or 11am-1pm New York time (1:30pm-3pm or 4pm-6pm London time) - does that work well for you?

[kailuowang]

In the last couple of years, Travic CI went through some significant changes including ownership change (owned by a private equity now) and pricing policy for OSS projects. As a result many OSS projects lost confidence in the platform.
Their concern might be justified after the recently security vulnerability discovered).

GH action, on the other hand, has been working way more consistently and faster. Most prominent Scala OSS projects have migrated to it.
That being said, there is no immediate urgency for this.

12:30PM New York Time , i.e. 5:30PM London time works best for me.

[rtyley]

Great, that all sounds good to me (GitHub Actions & the time!). I've sent a calendar invite for a Google Meet meeting (note, you might want to visit the link in advance if you haven't used Google Meet before, as you may have to restart your browser to grant audio/video permissions) at 12:30PM New York Time / 5:30PM London time - I've invited @regiskuckaertz , @kailuowang , and optionally @davidfurey & @mchv, I hope everyone who's interested can attend!

[rtyley]

I've corrected the calendar invite because I got it wrobg the first time - the meeting is tomorrow (Tuesday), not today!

Also, the project creator, the marvelous @philwills has also said he'll try to join us if he can!

[kailuowang]

Great! Looking forward to it.

…

On Mon, Sep 20, 2021, 11:26 AM Roberto Tyley ***@***.***> wrote: I've corrected the calendar invite because I got it wrobg the first time - the meeting is tomorrow (Tuesday), not today! Also, the project creator, the marvelous @philwills <https://github.com/philwills> has also said he'll try to join us if he can! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1203 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUKON7FK4V3ME5K6GNOIDUC5HBPANCNFSM5ECONDYA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rtyley]

I've added @kailuowang to the @scanamo/active-maintainers team, welcome again Kai!