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