I'd prefer not to add baggage to the PR review process. If someone wants to read PRs, they can. If someone wants to ask a question on a PR, they can. The dev mailing list is for asking questions too.
If someone wants to take on a coding task in a part of the code base that they are not super familiar with, then the hope is that someone with more experience will comment on the PR in a constructive way. We are also quite a long way away from making any big changes. I think the majority of the Pekko community are interested in releasing an open source equivalent of Akka with as few changes as possible. We can adjust the Pekko processes later if and when we want or need to implement big changes. On Fri, 28 Oct 2022 at 16:37, Michael Kohout <[email protected]> wrote: > > Inspired by Jean-Luc's statement that > > "People will naturally partition themselves in feeling they can rule on a > certain section of the code" > > Could the code review/approval process be used to *grow* the number of > people that are familiar with sections of the code? > > My naive idea would be a senior approver and a junior approver group for > each subproject and require approvals from both groups. If the change > under review isn't self-evident to the junior folks the review could be > used as an opportunity for knowledge transfer. > > > On Fri, Oct 28, 2022 at 9:51 AM Claude Warren, Jr > <[email protected]> wrote: > > > Just to be clear, the initial committer names in the Pekko proposal [1] are > > automatically members of the Pekko PPMC (Podling PMC) and will be PMC > > members if/when the project graduates. > > > > I proposed a process for adding new committers in a separate conversation. > > > > > > [1] https://cwiki.apache.org/confluence/display/INCUBATOR/PekkoProposal > > > > On Fri, Oct 28, 2022 at 2:16 PM Jean-Luc Deprez <[email protected]> > > wrote: > > > > > All the better, I guess 🤷♂️ > > > > > > On Fri, Oct 28, 2022 at 2:40 PM PJ Fanning <[email protected]> wrote: > > > > > > > The Pekko PMC has basically the same role and importance when Pekko is > > > > a podling as it will have when Pekko graduates to be a Top Level > > > > Project. > > > > > > > > There is an oversight role from the Incubator PMC but that does not > > > > lessen the importance of the Pekko PMC. > > > > > > > > On Fri, 28 Oct 2022 at 12:54, 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] > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
