I don’t think there is any confusion here, when the Apache process talks about cookie licking wrt to code ownership they specifically mention any mechanism which makes the code (directly or indirectly) look like its the sole responsibility of a group of individual/s. This can be done in many ways (such as using the @author tag on source files) and a CODEOWNERS file as you describe is also part of that (basically anything that implies code ownership in code). https://www.redhat.com/en/blog/dont-lick-cookie is a good article on the topic.
Unsurprisingly this is going to be an area of contention especially if we contrast how Akka was developed vs what is considered the Apache way. Akka had a set of core engineers working as part of Lightbend with deep and intimate knowledge of the Akka system and while that may work for a project that is being maintained and run by a company, as far as I understand this is contrary to the “Apache way” which is meant to be community driven. As stated by others there are logistical grounds as to why it can make sense for a project to be governed the way that Akka was, i.e. actors have an extremely high bar both for correctness and for performance and so having a set of people with the required expertise that can maintain this bar is one way of doing things. I guess we can approach this problem for another angle with the set of tools that we have, for example rather than having a CODEOWNERS file we can instead state that any change to core parts of the project (such as actors), needs a PIP (Pekko Improvement Proposal) with a tailored voting system for any design considerations. Parts of this problem can also be solved via tooling, i.e. triggering a benchmark run on CI when PR’s are made against projects to make sure there has been no performance regression, maybe there is also a JVM byte code analysis tool that can tell us when the outputted byte code has unintentionally changed when someone is doing basic refactoring on critical parts of the project (something like MIMA but checks for any diff in byte code rather than just breaking changes)? In other words extracting the “knowledge” out of a certain set of people (i.e. the “code owners”) into both processes and tooling which is visible and transparent to the community. Regards -- Matthew de Detrich Aiven Deutschland GmbH Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen m: +491603708037 w: aiven.io e: [email protected] On 29. Oct 2022, 07:56 +0200, Jean-Luc Deprez <[email protected]>, wrote: > Any chance there's some confusion in terminology here. > > When referring to CODEOWNERS, we're talking about the GitHub magic file and > it's functionality. > > That's not about laying claim, but e.g setting required reviewers in a pull > request. > > If you set code owners to repo level for PMC and PR required review from > code owners + 2 reviews. > > Anyone can contribute to any part of the code, any committer (Maintainer) > can merge PRs, after 2 PR approvals of which at least 1 comes from a PMC > member. > > On Fri, Oct 28, 2022, 23:42 Justin Mclean <[email protected]> wrote: > > > Hi, > > > > > 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. > > > > The project as a whole is responsible, and that is a shared responsibility > > of everyone. A project must follow the Apache grouping of (P)PMC members, > > committers and contributors/users. This is one of the graduation > > requirements. As I previously said, the use of CODEOWNERs is not > > encouraged. You can set expectations on how people should contribute to > > different parts of the project and document them, but all committers will > > have access to the entire codebase. > > > > Kind Regards, > > Justin > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > >
