One other point to discuss which just came to mind is whether it's possible to have a different number of approvals depending on the pekko module (in this case repo). For example with the core pekko repo at https://github.com/apache/incubator-pekko, requiring 2 approvals makes sense. Since we are dealing with core abstractions the bar needs to be set very high, basically on the same level as libraries in the JDK itself (I assume this is one of the reasons why Lightbend also requires 2 approvals for akka core). Any change on the core can theoretically have big consequences and having an extra person look at the PR's does mitigate the risks here.
However for other modules, such as https://github.com/apache/incubator-pekko-persistence-jdbc, only requiring a single approval makes more sense because the scope of such projects are smaller and also rely on the abstractions already defined in pekko core. This is also similar to what Lightbend does, for example from contributing on alpakka myself only one approval was necessary. This makes further sense when you just look at the numbers as well, a lot more people will be familiar with pekko core compared to the contrib modules. I would conclude that this is also a pretty rough approximation, for example there is a good case for https://github.com/apache/incubator-pekko-connectors-kafka is another outlier due to a non trivial/complex implementation and so should requrie 2 approvals rather than one (I assume Sean Glover would know more about this having worked on this in the past). On Thu, Oct 27, 2022 at 10:34 AM 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] > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* [email protected]
