There is no process documented for PIP. Please write one up and submit it as a change to the current document.
On Thu, Oct 27, 2022 at 9:55 AM Matthew Benedict de Detrich <[email protected]> wrote: > So I discussed this with Ryan Skraba and as far as my understanding is > that it is possible to do discussions outside of the [DISCUSS] mailing list > and there are other Apache projects that do this. > > If this is correct and we want to do the process this way (and from > initial impressions it does appear the Pekko community prefers discussions > over mailing lists), this is my conclusion on how the process would work. > > Anything that requires an official vote (i.e. creating a release, voting > on a PIP aka Pekko Improvement Proposal) has to be done on the dev mailing > list. Informal polling (such as what was done before with GitHub polls) is > fine to gauge community sentiment and also for topics that happen to have > various solutions to find out which one from the community has the most buy > in. > > It would be to get clarification from Apache on this, because the Apache > foundation has changed over time and while previously there was hard rules > it appears that they have been relaxed. We already have an example of this > with JIRA. > > And finally to set expectations for mentors and champions, the previous > Akka (and now Pekko) community (and the Scala community at large) doesn’t > use mailing lists, in fact the only projects that I can think of that does > use mailing lists are Spark and Kafka. So if there is a hard rule about > using the mailing list then of course we have to comply (i.e. voting for a > release and a PIP) but if there is a genuine choice between the mailing > list and GitHub native solutions I would suspect that it will almost always > fall to GitHub. > > Ultimately it would be good to get clarity on this. > > Regards > > -- > 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 27. Oct 2022, 10:34 +0200, Johannes Rudolph <[email protected]>, > wrote: > > Thanks everyone for setting this project up! > > > > Please pardon my ignorance of the details of common Apache processes, > > I guess this proposal is modeled after existing Apache projects. > > > > The process states: > > > > > All pull requests for code changes (e.g. changes that modify the code > execution) > > > > > > - must be associated with an issue. > > > - must be reviewed and approved by at least two committers who are not > the developer(s). > > > - must be voted on in the development list using the code > modifications process documented in the Apache voting process document > > > > The latter two points seem somewhat redundant. What's the rationale > > behind having this double process of gathering reviewing approvals > > first and then another vote on the mailing list? How does that usually > > work in practice? > > > > I understand (and agree) that the dev mailing list should be the > > definitive place to gather information and decide on development, so > > it's nice that you can just follow it and will never miss something. > > On the other hand, there's a continuum between trivial documentation > > changes and a significant functional code change. E.g. there are > > non-trivial code changes that are still small and might suffer from > > the extra overhead of the full process of review + vote. > > > > I'd propose to make review approvals on Github PRs binding in general > > but allow reviewers to promote a change to a discussion (+ vote) on > > the mailing list if deemed necessary (i.e. make the third point > > optional as long as no one objects to it). > > > > Are there existing Apache Projects that we could take as an example? > > (E.g. Kafka? > https://cwiki.apache.org/confluence/display/KAFKA/Contributing+Code+Changes > ) > > > > Thanks, > > Johannes > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > >
