To be clear, my point was probably useful for the moment when the changes are not the mechanical ones anymore.
Best, Josep On November 16, 2022 7:32:41 PM GMT+01:00, Matthew Benedict de Detrich <[email protected]> wrote: >As someone who has actually been helping out setting up PRs to bootstrap >pekko, due to the volume of trivial/mechanical PRs being created now I >suspect that changing it to 2 reviewers would noticeably slow down the >process. > >To date the majority of such PRs have been created and/or reviewed by >myself and PJ Fanning. > >To be clear, the trivial/mechanical PRs that are bring talked haven't >touched the actual pekko behaviour in any way, it's mainly >formatting/asm.yml to setup github repo settings/getting CI to >work/disabling some sbt checks so sbt can actually start etc etc > >On Wed, 16 Nov 2022, 19:24 Josep Prat, <[email protected]> wrote: > >> Hi all, >> In my opinion, I think we can go with 2 reviewers for all. In the >> beginning we will have plenty of people who would review PRs. If the >> process doesn't work we can start another discussion and see what we need >> to change. >> What do you all think? >> >> Best, >> Josep >> >> On November 16, 2022 7:05:36 PM GMT+01:00, 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] >> > >>
