General direction and next release?

[rageycomma]

I have a few projects which use serverless -- there are some bits and pieces that have always annoyed me about serverless that I'd like to fix, although the biggest one I fixed (the PR in compose). I also want to add in a dry-run mode so that DevOps can rest a bit easier.

For me, I'm happy to provide PRs to fix some bugs and do maintenance, however -- my main concerns currently are:

1. How frequently PRs get reviewed
2. What the plan is for the next release
3. How that gets tested correctly

I think there need to be discussions made around:

1. Adding in tooling for contributing (e.g. oxlint, git hooks, prettier run on commit, sonarcloud, etc)
2. Raising any obvious bugs which appear during the course of (1).
3. Looking at the serverless repo for bugs in 3.x and seeing which ones are major enough to fix for the release.
4. Consider adding more meaningful tests in compose and serverless so the logic is tested a bit more thoroughly (some of the logic I have seen just tests things get called, which isn't ideal)
5. Consider adding in onboarding documentation for new developers so they know what to do and where to start.
6. What the next version is, and what then will be in it and who will do it.

I'm happy to do these. I'd like to just see a community-run version of this project and start adding in things necessary to make it easier for developers to get started adding features and bugfixes to the project, given it's an Open Source project and not a semi-commercial one any more.

I had contemplated forking the project before, but now there's a fork -- I feel we should work together :)

[mnapoli]

Hi, to answer your questions:

How frequently PRs get reviewed

When I have time :)

What the plan is for the next release

I fix bugs that affect my users and customers. I merge PRs from other people that are easy to merge. And I release that.

How that gets tested correctly

There's a good test suite in the repo, feel free to add more tests if you want.

Also there's this section in the README if that helps get an idea of the goal of this fork:

The repository has been created and is maintained by Bref maintainers and contributors. The main goal of this repository is to provide continuity for Bref users, so that these Bref projects keep working for the next 5 years. No major new features are planned. However, community contributions to keep the project running (even for languages other than PHP), like adding support to new runtime versions, adapting to AWS changes, bugfixes, and other small improvements are welcome.

[rageycomma]

I mean, major new features are fair enough -- I'm not interested in adding massive new stuff, just bits that make my life easier. I wanted to get an idea of what would be worth me adding them in.

Are there any points in the 5 above (excluding option 6) that you'd be opposed to? And if I were to create a PR for, would it be something you'd accept? I just wanted to get an idea of what is worth doing.

[mnapoli]

Adding in tooling for contributing (e.g. oxlint, git hooks, prettier run on commit, sonarcloud, etc)

I have trauma with git hooks 😂 I don't think that needs to be set up in the repository for everyone, but feel free to set it up on your machine. There are GitHub Actions anyway for PRs.

prettier on commit (in GitHub Actions) could be cool to automate.

As for other tools, I don't know what they do/what value they bring.

Raising any obvious bugs which appear during the course of (1).

Sounds good!

Looking at the serverless repo for bugs in 3.x and seeing which ones are major enough to fix for the release.

Feel free to fix bugs 👍

Consider adding more meaningful tests in compose and serverless so the logic is tested a bit more thoroughly (some of the logic I have seen just tests things get called, which isn't ideal)

Sounds good!

Consider adding in onboarding documentation for new developers so they know what to do and where to start.

There's https://github.com/oss-serverless/serverless/blob/main/docs/getting-started.md and the rest of the docs. These have been the official docs for the project for years, and we know they work OK. If you spot improvements feel free to send PRs. I'm cautious with any plan to radically change this, I'm not opposed to this, but while I think there are things that could be improved (definitely) I don't think any complete rewrite of these docs will be good "by default". So I think the execution matters, that's what I'd judge.

What the next version is, and what then will be in it and who will do it.

I release when there are PRs merged, that's what the new version is 😄 As simple as it gets.

[rageycomma]

Re: hooks -- I've not had that same experience, with the older version of husky it happens seamlessly so the dev tries to commit and it'd then run the linter/prettier and prevent commit if there are issues. Usually this is easier if it's on push so devs can make commits in haste but are told if their changes are poorly formed, don't work, tests are broken, etc. In my opinion this makes the quality much better and removes the need for reviewing on GitHub because if the dev can't push, it means the code doesn't work and it's not ready for PR.

The sonarcloud stuff I think is free for FOSS projects (https://www.sonarsource.com/products/sonarcloud/) and is static analysis and security analysis to prevent potential security or stability issues from creeping in. There are other free tools which do a similar analysis as well, but they are useful for sure.

Just one minor point -- the proposed onboarding documentation is for developers (e.g. to do with the code and bugfixing so a developer knows what PRs will get accepted, what won't etc). That documentation you linked to is to do with getting started with the serverless CLI.

I release when there are PRs merged, that's what the new version is 😄 As simple as it gets.

So just when you feel there are enough changes, you will create a new version?

[mnapoli]

Ah ok I misunderstood the kind of docs you wanted. Sounds good.

Sonarcloud seems to duplicate what dependabots does already.

So just when you feel there are enough changes, you will create a new version?

Yes