Well, git comments can be deleted. When just edited, you can see the history of the edits. But why would anyone delete something malevolently, other than exercising one's right to be forgotten.
In e.g. the linux kernel all the information relevant to the change goes in the Git log, which is the true audit trail of your code. Not saying that process should be adopted, but I do think the commit messages should be the primary source of information to reconstruct the reasoning behind code, where everything else is at most informational. On Thu, Oct 27, 2022 at 4:51 PM Jean-Baptiste Onofré <[email protected]> wrote: > 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] > > > > > > > > > > > > > >
