I agree with Johannes. I've been involved with a few ASF projects and have not come across a need for formal mailing list votes on code changes. Maybe this is the norm but I'd be interested in seeing a project that has this project to review how it works in practice.
My default position matches Johannes'. I'd fear that development would be significantly slower with having to vote on everything and will team members be up for having so many votes? By all means, if the PR goes to discussion and the discussion shows some variety in opinions, then a vote may be a good way to proceed. One compromise perhaps would be to set some minimum time before a PR can be merged - to allow some time for team members to review. It probably would not be ideal to get a PR and have it get 2 positive reviews and it then be merged all on the same day. Another thing we need to decide fairly soon is the branching strategy. There has been some discussion about producing a Pekko release candidate that closely matches Akka 2.6.x (last Apache licensed release versions, generally) but there also appears to be some support for making some changes. We could have a branch dedicated to the 2nd release so that PRs that are not for the 1st release can be merged and not go stale. We would probably need some guidelines about which branches PRs should target. On Thu, 27 Oct 2022 at 09:34, Johannes Rudolph <[email protected]> wrote: > > Thanks everyone for setting this project up! > > Please pardon my ignorance of the details of common Apache processes, > I guess this proposal is modeled after existing Apache projects. > > The process states: > > > All pull requests for code changes (e.g. changes that modify the code > > execution) > > > > - must be associated with an issue. > > - must be reviewed and approved by at least two committers who are not the > > developer(s). > > - must be voted on in the development list using the code modifications > > process documented in the Apache voting process document > > The latter two points seem somewhat redundant. What's the rationale > behind having this double process of gathering reviewing approvals > first and then another vote on the mailing list? How does that usually > work in practice? > > I understand (and agree) that the dev mailing list should be the > definitive place to gather information and decide on development, so > it's nice that you can just follow it and will never miss something. > On the other hand, there's a continuum between trivial documentation > changes and a significant functional code change. E.g. there are > non-trivial code changes that are still small and might suffer from > the extra overhead of the full process of review + vote. > > I'd propose to make review approvals on Github PRs binding in general > but allow reviewers to promote a change to a discussion (+ vote) on > the mailing list if deemed necessary (i.e. make the third point > optional as long as no one objects to it). > > 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) > > Thanks, > Johannes > > --------------------------------------------------------------------- > 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]
