I was talking about a vote on an existing PR, which is what item 2.3.c appears to be proposing.
Ultimately I think we should have a PIP for major/breaking changes before a PR is made. That would include things like: 1. new Pekko features/libraries 2. changes to public APIs 3. changes to wire protocol 4. large changes across many Pekko components So if that’s the intention, we probably want to insert an item before 2.2 with something like: “Some more complex or risky changes should be discussed and voted on prior to submitting a pull request. Such changes include …” We should define a more formalized process for this case, but maybe as a starting point we can just require a discussion and vote on the dev list. On Wed, Nov 2, 2022 at 01:23 Josep Prat <[email protected]> wrote: > 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] > >> > > >> > > >> >
