+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] > > > > > >
