Hi all, I think point 2.3.c shouldn't be required for *all code changes*, but rather only for changes that break backwards compatibility (and probably binary backwards compatibility). Akka had a really strict rule (which IMO we should carry with us) about binary compatibility. I propose to make point 2.3.c conditional to the change being backwards incompatible.
Best, Josep > On 2022/11/01 14:40 CET Claude Warren, Jr <[email protected]> > wrote: > > > 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] > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
