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