All good then, in agreement On Wed, 16 Nov 2022, 19:47 Josep Prat, <[email protected]> wrote:
> 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] > >> > > >> >
