Hi, The idea of submitting some changes to a vote (for example the backwards compatibility breaking ones) is to discuss and submit the discussion to a vote before the whole PR is made.
Some other Apache projects are already doing this. One can take a look at Kafka, Cassandra or Flink and their KIP, CIP and FLIP (Xxxx Improvement Process). Some concrete examples might be: - Remove Scala 2.12 support - Use Loom internally at Akka Before writing the whole PR, these 2 changes could be brought up in a discussion, and once all the contention points are addressed it could be brought up to a vote. Best, On November 2, 2022 6:49:46 AM GMT+01:00, Greg Methvin <[email protected]> wrote: >What value do we get out of a vote versus using the existing features of >GitHub PR reviews? If a project member identifies risk in a PR, they can >just request changes on the PR. That essentially works the same as a veto >in the code modifications voting process, except that veto can be withdrawn >later after changes are made. > >I guess one advantage of a vote is that it's on the mailing list, and maybe >some people are paying more attention to the mailing list than GitHub? > >On Tue, Nov 1, 2022 at 11:25 AM Jean-Luc Deprez <[email protected]> >wrote: > >> Sure feels like there was some consensus on voting for each PR is overdoing >> it. >> >> Perhaps generalize the compatibility to "risk". E.g. I can perfectly >> imagine that doing a "performance optimization" to a dispatching algorithm >> would be expected to not introduce any compatibility issues, but it seems >> like a vote could still be justified. >> >> Though I guess most of these would be matter of negotiation/consensus, e.g. >> phasing in settings. >> >> So something like, "If a project member detects risk as part of the review >> (e.g. compatibility or performance), these should be addressed or >> mitigated. The required actions can be discussed in the PR, but a >> concluding vote should be made before merge." >> >> On Tue, Nov 1, 2022, 16:16 Josep Prat <[email protected]> wrote: >> >> > 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] >> .invalid> >> > 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] >> > >> > >>
