That sure smells like a more contemporary approach, while still respecting the spirit of the Apache process.
Note: of all the tools on the tool belt, GH discussions I'm not particularly fond off. The half baked threaded view is rather unpractical. So I wouldn't mind that there's not too much focus on that one. The one arg for would be that the integration with the remainder of the GH tooling is probably better. Which is a possible discriminator. Tied to code, is GH tools, when it's still immaterial, like the PIP, wiki (+ list ). Though I guess even those I've seen done in a separate Git repo in markdown. On Thu, Oct 27, 2022, 17:59 Matthew Benedict de Detrich <[email protected]> wrote: > So I had a look at Apache Airflow which is a top level project that does > use Github’s tools more extensively than other projects. They use GitHub > discussions (see https://github.com/apache/airflow/discussions) as the > primary method of communication rather than the dev/user mailing list (see > https://lists.apache.org/[email protected]). Their dev > mailing list appears to be exclusively for formal votes on releases, > announcement of releases as well as AIP’s (DISCUSS/VOTE). Likewise their > users mailing list (see > https://lists.apache.org/[email protected]) is largely > vacant apart from announcements of new versions of Apache Airflow, as a > replacement they also use GitHub discussions, specifically Q&A and general > (see https://github.com/apache/airflow/discussions/categories/q-a and > https://github.com/apache/airflow/discussions/categories/general > respectively). > > Apache Airflow has AIP (Airflow Improvement Proposal) which are listed on > the Apache Wiki (see > https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals) > and they do create [DISCUSS]/[VOTE] proposals for the AIP’s on their dev > mailing list however the community also does use informal polling via > GitHub poll discussions (see > https://github.com/apache/airflow/discussions/24855 as an example albeit > its the only one) to gauge community on questions with Github poll’s in a > similar way that Pekko did. > > For pull requests they require a single GitHub approval from the committer > organisation rather than two (https://github.com/apache/airflow/pull/27326 is > an example of a PR that was merged with a single approval). Not sure what > the distinction here is, but at least for Pekko I would say that we also > require 2 votes since that is also what Akka has/had (note this needs to be > decided/voted upon). > > 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, 17:18 +0200, Claude Warren, Jr > <[email protected]>, > wrote: > > The Apache process is mostly up to the group running the project. However > > there are a few things that have to be done to satisfy the requirements > of > > legal and the board. > > > > > - 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 > > > > These items do seem redundant. However, the first is within the pull > > request itself. Two new eyes to look at the code. The second is a record > > on the mailing list that it was accepted. > > > > There are different levels of preservation associated with each. Apache > > considers the mailing list to be the repository of truth: It it isn't on > > the mailing list it didn't happen. > > Git (where the pull requests and such occur) can be and often are > rewritten > > meaning that some history can be lost or obfuscated. > > > > I put those up so we can have these discussions. > > > > Your comment about a continuum is a valid one. Please write up your > > change as a proposal. Specify the section numbers from the original > > document. I think you are talking about 2.3.b and 2.3.c > > > > > > > > On Thu, Oct 27, 2022 at 9:34 AM 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] > > > > > > >
