Already commented on the PR but will repost it below Historically akka always required 2 approvals, even for trivial changes. I will say however in terms of practicality especially right now with a lot of mechanical and trivial changes needed to get the project bootstrapped, going with 1 should be fine.
We can revisit this process later, I personally think that requiring 2 reviewers once the project is setup has merit especially since at that point in time we will also start seeing non trivial functional changes. On Wed, 16 Nov 2022, 19:05 PJ Fanning, <[email protected]> wrote: > Can we require 2 reviewers for all PRs? The current proposal suggests that > trivial changes just need 1 review - but this complicates adding automated > rules in Github. > > https://github.com/apache/incubator-pekko/pull/52 > > If we make 2 the min number of reviews then the larger or more complicated > changes will be enforced to have 2 reviews before merges are allowed. > > On 2022/11/08 04:56:22 Salar Rahmanian wrote: > > +1 to use wiki like Cassandra project. > > > > -- > > Regards, > > Salar Rahmanian > > email: [email protected] > > > > On 11/3/22 1:30 AM, Claude Warren, Jr wrote: > > > We do have a wiki. The Cassandra project has CEPs created in the > Cassandra > > > wiki [1]. This keeps long documents out of the email list and > provides a > > > single Apache controlled space to record the permanent documents. I > think > > > we should make use of the pekko wiki to document all processes and > PIPs as > > > well as provide other information that users/developers may want. > > > > > > > > > [1] > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 > > > > > > On Thu, Nov 3, 2022 at 1:47 AM Greg Methvin <[email protected]> wrote: > > > > > >> +1 on all these suggestions. > > >> > > >> We also have to decide on the details of how PIP should work. My > rough idea > > >> is: > > >> 1. Create a PIP ticket on GitHub using a predefined PIP template. > > >> 2. Start a discussion on the mailing list referencing the ticket. > > >> 3. Once a consensus is reached, perform a vote using the Apache voting > > >> process. > > >> 4. If the PIP passes, the author and other contributors create PRs > > >> referencing the original PIP ticket on GitHub. Code review follows the > > >> normal code review process. > > >> > > >> I'm thinking we probably should have an entirely separate PIP section > in > > >> our process doc? > > >> > > >> On Wed, Nov 2, 2022 at 7:05 AM Claude Warren, Jr > > >> <[email protected]> wrote: > > >> > > >>> I suggest changing "Examples of such issues include:" to "Examples of > > >> such > > >>> issues include, but are not limited to:" > > >>> > > >>> On Wed, Nov 2, 2022 at 1:46 PM Matthew Benedict de Detrich > > >>> <[email protected]> wrote: > > >>> > > >>>>> New point 3 (pushing down existing point 3 to 4, etc.) > > >>>> 3. For major/breaking changes, we require that a Pekko Improvement > > >>>> Process (PIP) proposal is submitted on the dev mailing list before a > > >>>> PR is made. After allowing some time for discussion, a vote will be > > >>>> required on the dev mailing list using the code modifications > process > > >>>> documented in the Apache voting process document. When we have > general > > >>>> agreement on the proposal, we can proceed to submitting PRs. > Examples > > >>>> of such issues include: > > >>>> a. new Pekko features/libraries > > >>>> b. changes to public APIs > > >>>> c. significant upgrades to jar dependencies > > >>>> d. changes to wire protocol > > >>>> e. large changes across many Pekko components > > >>>> > > >>>> My suggestion would be to further equivocate this so that its more > > >>>> accurate. For example, for both the contributors and users of Akka > (and > > >>> now > > >>>> Pekko), breaking binary compatibility is something that was checked > > >> with > > >>>> sbt-mima (see https://github.com/lightbend/mima). Furthermore, > > >> forwards > > >>>> breaking changes that weren’t major was actually allowed in with > just a > > >>>> standard basic review (which also involved putting in ProblemFilters > > >> into > > >>>> sbt-mima, see the currently existing mina-filters folders). Such > > >> changes > > >>>> were also sometimes put behind the @ApiMayChange annotation if there > > >> was > > >>> a > > >>>> chance that the API may change future because but the merits of > adding > > >> in > > >>>> the change outweighed perfect stability, this was quite a common > > >>> occurrence > > >>>> in fast moving modules such as akka (and now pekko) streams > > >>>> > > >>>> There is also another @InternalApi annotation whereby you can break > > >>>> anything you want and is only meant for internal use. > > >>>> > > >>>> It would be good to also add these details into the process > document. I > > >>>> think there is a lot of merit in being quite precise here for what > > >>> requires > > >>>> a Pekko Improvement Proposal because we can run the risk of making > it > > >> to > > >>>> budersome to contribute to Pekko if the keep on throwing the “this > > >> needs > > >>> a > > >>>> Pekko Improvement Proposal” due to unclear rules. > > >>>> > > >>>> -- > > >>>> 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] > > >>>> On 2. Nov 2022, 14:34 +0100, PJ Fanning <[email protected]>, > wrote: > > >>>>> Can I suggest these amendments to > > >>>>> https://cwiki.apache.org/confluence/display/PEKKO/Processes ? I'm > > >>>>> happy for any of these proposed changes to be adjusted or discussed > > >>>>> further. > > >>>>> > > >>>>> Change > > >>>>> 1. Defects are recorded in the git issue for the associated Pekko > > >>> module. > > >>>>> to > > >>>>> 1. Defects are recorded in the Github issue tracker for the > > >> associated > > >>>>> Pekko module. > > >>>>> > > >>>>> New point 3 (pushing down existing point 3 to 4, etc.) > > >>>>> 3. For major/breaking changes, we require that a Pekko Improvement > > >>>>> Process (PIP) proposal is submitted on the dev mailing list before > a > > >>>>> PR is made. After allowing some time for discussion, a vote will be > > >>>>> required on the dev mailing list using the code modifications > process > > >>>>> documented in the Apache voting process document. When we have > > >> general > > >>>>> agreement on the proposal, we can proceed to submitting PRs. > Examples > > >>>>> of such issues include: > > >>>>> a. new Pekko features/libraries > > >>>>> b. changes to public APIs > > >>>>> c. significant upgrades to jar dependencies > > >>>>> d. changes to wire protocol > > >>>>> e. large changes across many Pekko components > > >>>>> > > >>>>> Change 3c (which becomes 4c because of new point 3 above) > > >>>>> > > >>>>> c. if a Pekko committer requests that the PR changes should be > > >>>>> discussed more widely, the changes should be discussed on the dev > > >>>>> mailing list and voted on using the code modifications process > > >>>>> documented in the Apache voting process document. > > >>>>> > > >>>>> Change 5c (which becomes 6c because of new point 3 above) > > >>>>> > > >>>>> c. if a Pekko committer requests that the PR changes should be > > >>>>> discussed more widely, the changes should be discussed on the dev > > >>>>> mailing list and voted on using the code modifications process > > >>>>> documented in the Apache voting process document. > > >>>>> > > >>>>> On Thu, 27 Oct 2022 at 09:55, Claude Warren, Jr > > >>>>> <[email protected]> wrote: > > >>>>>> One of the first things this team needs to do is to decide how > > >>>> development > > >>>>>> will be done. I have drafted a process document to kick this > > >>> discussion > > >>>>>> off. > > >>>>>> > > >>>>>> The draft document is found at > > >>>>>> https://cwiki.apache.org/confluence/display/PEKKO/Processes > > >>>>>> > > >>>>>> For purposes of this discussion: > > >>>>>> > > >>>>>> 1. No changes will be made until a code modification vote is > taken. > > >>> See > > >>>>>> https://www.apache.org/foundation/voting.html for requirements. > > >> For > > >>>>>> those of you who have edit access to the document please do not > > >>> change > > >>>> it > > >>>>>> until we have a vote. > > >>>>>> 2. Committers and Mentors have binding votes. All other votes are > > >>>>>> advisory. > > >>>>>> 3. Discussions of proposed changes must be posted to the > > >>>>>> [email protected] mailing list and the subject should be > > >> prefixed > > >>>>>> with "[DISCUSS]". > > >>>>>> 4. Calls for votes on the proposed changes must be made on the > > >>>>>> [email protected] mailing list and the subject should be > > >> prefixed > > >>>>>> with "[VOTE]" to make it easy to identify. > > >>>>>> 5. Results of votes will be published on the dev mailing list with > > >>>>>> "[RESULT]" prefixing the subject. > > >>>>>> 6. A vote to accept the document may be taken once all proposed > > >>> changes > > >>>>>> are voted on. > > >>>>>> 7. A vote to accept the document will close all discussion under > > >> the > > >>>>>> process documented in this email > > >>>>>> 8. Once the document is accepted any subsequent changes will be > > >>>>>> performed as specified in the accepted process document. > > >>>>>> > > >>>>>> The purpose of this exercise is to arrive at a consensus for how > > >> this > > >>>>>> project will operate within the guidelines and requirements of the > > >>>> Apache > > >>>>>> organization. > > >>>>>> > > >>>>>> Thanks for participating, > > >>>>>> Claude > > >>>>> > --------------------------------------------------------------------- > > >>>>> To unsubscribe, e-mail: [email protected] > > >>>>> For additional commands, e-mail: [email protected] > > >>>>> > > -- > > Regards, > > Salar Rahmanian > > email: [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] > >
