It seems to me the whole CODEOWNERS discussion is really about the distinction between the cathedral and the bazaar [1] forms of project management. Akka, from my perspective, seems to have been a cathedral project (few people controlling the development direction) whereas pekko, being an Apache project, will be more of a bazaar style project.
There are things about Apache projects to keep in mind: - Anyone can contribute (patches, documentation, etc.) - Generally any committer can commit code/documentation to the main branch. - Anyone can become a committer based on merit. They produce clean contributions, with tests (if appropriate), in the form that the project wants. (Specific policy here needs to be documented). - The project management committee (PMC -- PPMC for podlings like Pekko) are comitters that have volunteered to give more time to the functioning of the project. They are the ones responsible for reporting the project status to the Apache board (Incubator PMC for podlings). They are the ones that get notified when new security issues are identified. They don't have more power, they have more responsibility. They have agreed to volunteer more time. See PMC guide [2] and PMC Governance Overview [3] for more details. - Any comitter can be added to the PMC. It is up to the project to determine how this is done. But once a committer is selected to be a PMC member there is a process to follow [4] - There is a PMC chair; again not more power, more responsibility. How the chair is selected is up to the project, though they do have to be a member of the PMC. So yes there is a hierarchy, but it is not a hierarchy of power, it is a hierarchy of responsibility. Those at the top do the most paperwork. Those at the bottom have the most fun. So when it comes to merging pull requests the project has many options: - Any committer can review and accept any pull request. - Any PCM member can review and accept any pull request. - A pull request can be accepted after review and acceptance of 2 or more committers. - A pull request can be accepted after review and acceptance by a PCM member and a committer - Any combination of the above - none of the above but something different. - ... The trick is to balance the need for - the contribution not to break things - the contribution to be understandable - the result of the contribution to be understood (multiple people understand how it changes current operation, why, and what the side effects are) - speed of response / welcoming community -- pull requests should not sit idly by and have no activity. Prospective contributors should be welcomed. - time to review/think about complex contributions. So it falls to this group to come up with a process that works for the group within the Apache framework. The current proposed process [5] states that "all pull requests for code changes" 2.3.b must be reviewed and approved by at least two committers who are not the developer(s). 2.3.c must be voted on in the development list using the *code modifications* process documented in the Apache voting process <https://www.apache.org/foundation/voting.html>document This is a high bar to pass. Not the highest I have seen, but not a low bar either. There has been lots of discussion here about how to approve the code, so propose a change to the text if you think this is not the right bar. Claude [1] http://www.catb.org/~esr/writings/cathedral-bazaar/ [2] https://www.apache.org/dev/pmc.html [3] https://www.apache.org/foundation/governance/pmcs [4] https://www.apache.org/dev/pmc.html#newpmc [5] https://cwiki.apache.org/confluence/display/PEKKO/Processes On Fri, Oct 28, 2022 at 12:54 PM Jean-Luc Deprez <[email protected]> wrote: > What is set in CODEOWNERS is somewhat "set in stone". So I'd argue to keep > that broad, like PMC(ish). People will naturally partition themselves in > feeling they can rule on a certain section of the code. Without inhibiting > progress, waiting for a very small set of people to revive. > > I think the PMC ends up being a large group anyway, especially for a > project of this size. The fact that you need 3+ PMC votes + majority, sure > seems to indicate that. > > (btw, I'm well aware that the whole PMC thing only formally activates when > graduating from the incubator, but I'd argue that the current start list of > committers is indicative for what could be PMC?) > > On Fri, Oct 28, 2022 at 11:31 AM Johannes Rudolph < > [email protected]> wrote: > > > 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] > > > > >
