We can always a summary / vote on a mailing list. It’s what we do on most of Apache projects.
Regards JB Le jeu. 27 oct. 2022 à 16:48, Claude Warren, Jr <[email protected]> a écrit : > My issue with git comments and discussions is that they can be edited. > The purpose of putting it on the mailing list is that there is a permanent > record. "If it is not in the mailing list it didn't happen" is a common > refrain around Apache for exactly this reason. Git allows you to rewrite > history, the mailing list does not. > > However, I see the advantage of small discussion on git and larger > discussions on the mailing list. > > > > On Thu, Oct 27, 2022 at 3:16 PM Jean-Luc Deprez <[email protected]> > wrote: > > > Well, I'd imagine that [DISCUSS] threads is the nurturing ground for > > assessing the sense of large developments. > > > > Once there's an issue in GH, that would be the place to continue the > > discussion and once there code + a PR that would be the place where the > > discussion happens side-by-side the code. > > > > When it comes to voting, there's little question about releases, but for > > every PR seems like the process step too much. > > > > I agree with prior speakers that getting the PR/branch protection setup > > right. E.g. requiring approval from at least 1 of a subset of people > > (which once graduated would be Pekko PMC). I think this can be achieved > > with CODEOWNERS + a team handle setup. > > > > > > On 2022/10/27 09:57:41 Jean-Baptiste Onofré wrote: > > > Hi, > > > > > > I agree with Johannes and PJ. > > > I'm working on some Apache projects, and only "big" > > > changes/refactoring are discussed on the mailing list (you can take a > > > look at the Karaf dev mailing list as example). > > > As an example, we launched Karaf Minho in the community. As it's a > > > major refactoring/subproject in Karaf, we discussed it on the mailing > > > list and we voted for Minho. > > > I would say that the "regular" project activity goes on GitHub issues > or > > Jira. > > > > > > I think it's great to: > > > - create issues and corresponding PRs for each bug fix/new > > > feature/improvement. Community can comment on the issue and/or PR. > > > - as soon as you consider the change bigger, where community consensus > > > or advice makes sense, than we can go on discussion/vote on the dev > > > mailing list > > > > > > As reminder, during the incubation phase, we have three main > objectives: > > > - mentor/explain/adopt the Apache way > > > - build and grow the community (involving promotion of the project, > etc) > > > - follow incubator/Apache rules in terms of releases, legal, > trademarks, > > IP, etc > > > These three main objectives are detailed in the maturity model matrix > > > that we will have to complete before talking about graduation as TLP. > > > > > > Let's keep the fluidity and moving forward on project bootstrap ;) > > > > > > Thanks > > > Regards > > > JB > > > > > > On Thu, Oct 27, 2022 at 10:57 AM PJ Fanning <[email protected]> wrote: > > > > > > > > I agree with Johannes. I've been involved with a few ASF projects and > > > > have not come across a need for formal mailing list votes on code > > > > changes. Maybe this is the norm but I'd be interested in seeing a > > > > project that has this project to review how it works in practice. > > > > > > > > My default position matches Johannes'. I'd fear that development > would > > > > be significantly slower with having to vote on everything and will > > > > team members be up for having so many votes? By all means, if the PR > > > > goes to discussion and the discussion shows some variety in opinions, > > > > then a vote may be a good way to proceed. > > > > > > > > One compromise perhaps would be to set some minimum time before a PR > > > > can be merged - to allow some time for team members to review. It > > > > probably would not be ideal to get a PR and have it get 2 positive > > > > reviews and it then be merged all on the same day. > > > > > > > > Another thing we need to decide fairly soon is the branching > strategy. > > > > There has been some discussion about producing a Pekko release > > > > candidate that closely matches Akka 2.6.x (last Apache licensed > > > > release versions, generally) but there also appears to be some > support > > > > for making some changes. We could have a branch dedicated to the 2nd > > > > release so that PRs that are not for the 1st release can be merged > and > > > > not go stale. We would probably need some guidelines about which > > > > branches PRs should target. > > > > > > > > On Thu, 27 Oct 2022 at 09:34, 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] > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
