Thanks to all that input. One thing to keep in mind is that Akka/Pekko codebase is already a mature project with all its consequences:
* There are parts of the code base that are very stable and will likely not change a lot. If we hope to carry part of the user base, we will also inherit part of the stability expectations towards these parts (especially APIs in akka-actor, akka-stream, akka-http, etc) * Some parts like akka-stream are stable and have a big API that gives the impression that you could easily add more but which needs careful vetting in many small detailed cases to keep maintenance tractable. * Some parts like alpakka connectors have been contributed by a big, diverse community (often one-time engagements) and are in different states of code quality. Many one of those did not have any active maintainer. Here it is important to set expectations and have low hurdles for contributions. * Some parts like the clustering and persistence parts are relatively complex and have complex test suites making contribution non-trivial. It will be a main task to figure out how to evolve such a complex project and how to solve the friction between keeping stability but also figuring out ways and places to evolve. The only way to get that done is to find enough shoulders to spread the load. Some mechanism like CODEOWNERS will be needed to figure out who is responsible (even if overall ownership is shared, of course) for which part of the code. Saying that everyone is responsible for everything as a whole is not realistic. It's also not a realistic expectation for anyone to be able to keep track of everything that might go on in all parts of the code. I would propose to identify parts of the whole project that are sufficiently standalone, define expectations for each part, and let the committers divide themselves between those subprojects. Then after a release (or periodically) review if there are enough people available for every part of the project and see how to improve. That said, I think we should keep the amount of policies small and leave room for flexibility where needed. I would not move away from review then commit which seems to be the accepted standard in the existing community but maybe a single reviewer will suffice. (Not sure what that means about PMC's vs regular committer's votes. Will we need/have lots of PMCs to make that work?) Johannes On Thu, Oct 27, 2022 at 10:57 PM Justin Mclean <[email protected]> wrote: > > Hi, > > > Please pardon my ignorance of the details of common Apache processes, > > I guess this proposal is modeled after existing Apache projects. > > There is no ASF requirements for this process, and each project can decide > what it should be. That being said, most projects select CTR (commit then > review). Having an RTC (review then commit) style process, especially > requiring two approvals, seems unnecessary to me. I would try and keep it as > simple as possible and reduce the number of rules. The more complex you make > this , the less likely the project will attract new committers or will > exclude groups of committers. > > > Are there existing Apache Projects that we could take as an example? > > (E.g. Kafka? > > https://cwiki.apache.org/confluence/display/KAFKA/Contributing+Code+Changes) > > I would avoid emulating projects like Kafka, that encourage a high committer > bar. They are the exception in how ASF projects operate rather than what is > typical of an Apache project. > > Kind Regards, > Justin > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
