Open up the gates for all maintainers

This is part of the proposal in https://github.com/lerna/lerna/issues/2703#issuecomment-693679020 If @evocateur is the only gatekeeper at the moment (as mentioned in https://github.com/lerna/lerna/issues/2703#issuecomment-680939198), open up the gates for all maintainers at the risk publishing regressions. This is an acceptable trade off because I believe the only alternative is to let lerna wither away before it’s time was up. There are ways to mitigate this risk of course. I’m not sure what the state of the unit and integration tests are but that’s a place to start. pre-release candidates are another option to help prevent bugs from entering into consumers who haven’t opted in to the @next release.

Problem

Having all maintenance go through @evocateur is a huge bottleneck. This was mentioned in @MikeActually’s comment https://github.com/lerna/lerna/issues/2703#issuecomment-680939198 and I haven’t confirmed this with any other maintainers or contributors but if this is the case, this should be addressed ASAP because there’s no way this can continue.

Currently, all maintenance must go through @evocateur , since he is most familiar with the project and is one of two people with access to publish changes. Would love to hear what would be acceptable from the owners of this project to help find a LTS model for this package, instead of relying on 1 person to contribute to it in their free time.

[Robbie-Cook]

@hzoo Thank you for your response. I appreciate all your effort.

Having said that, some of the things you have said in here do worry me a little. To me it seems like what you are saying is:

• @hzoo and @evocateur do not want to maintain this.
• Forks will not be merged into Lerna, ever

To clarify, when I mean forking, I don’t mean one would fork and release under the Lerna package or name. It would be a different name or a scoped module that people could use.

• We’re not going to add any maintainers
• Go away and use your own fork.

Dropping a package with 1 million weekly downloads seems like a bit of a problem, even just from a security standpoint.

Forking is a really bad solution, because the goal is to coordinate, and not splinter, a package.

The community could create a new branch & package called lerna@next, with greater access permissions, say @goldhand and @MikeActually . This way regressions won’t make it into the old branches, access permissions can be opened on one branch only (https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/enabling-branch-restrictions), and we don’t have to create an entirely new package that does the exact same thing, but is maintained.

[MikeActually]

@hzoo - one thing that is confusing to me is that yourself and @evocateur have expressed a desire to help groom additional maintainers, but whenever interest arises, it seems like you both are worried about giving up control. I think you and @evocateur need to decide what the go-forward plan is for this project. Forking is not too reasonable as it wouldn’t easily allow for rolling out the updated library leveraging the NPM distribution system, unless you are ok with deploying releases from a forked repo.

I’d also point out that Git allows rollbacks, and, any undesirable changes can be reverted. Lastly, I think you are highlighting the perils of a single point of failure for a project. I have no problem helping review PRs, it’s a major component of my day-to-day outside of Github, if that helps with gatekeeping undesirable outcomes. I think it’s also good to manage backlog, but, as you point, the community needs guidance regarding what is allowed/not allowed.

I think nearly everyone who is involved here really is trying to help this project. Can you at least give us some dates/milestones as to what we can expect and when? Especially regarding improving the process surrounding PRs, approvals, and releases. Waiting for someone to address a couple of PRs once or twice a year is not really working out too well.