I know Apache Pulsar uses GitHub issues: https://github.com/apache/pulsar/wiki#pulsar-improvement-proposals. They may be a special exception though.
I don't have a strong preference either way though. GitHub makes it slightly easier for people to submit a PIP since they don't need an account on Confluence, but in practice I suppose most people submitting PIPs will be Apache committers anyway. On Wed, Nov 2, 2022 at 10:54 PM Matthew Benedict de Detrich <[email protected]> wrote: > Regarding creating Pekko Improvement Proposals, AFAIK we have to follow an > already existing process which is creating a wiki page on the Apache > confluent page, i.e. see the Apache Airflow Page as an example ( > https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals > ). > > I am not aware of any other approved way of doing it. > > -- > 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 3. Nov 2022 at 02:47 +0100, 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] > > > > > > > > > > > > >
