Hi Brennan, I agree with your reasoning and welcome the change, but let me expand on the initial reasoning. below.
On 2019/12/21 07:56:35, Brennan Ashton <bash...@brennanashton.com> wrote: > On Fri, Dec 20, 2019, 11:22 PM David Sidrane <davi...@apache.org> wrote: > > > All, > > > > Please help flesh this out. > > > > Proposed Workflow Requirements (REQ) and Derived Requirements (DREQ) > > > > REQ1) master is branches of apps and nuttx have to always build > > REQ1.1) ALL development work is done on branches. > > DREQ1.1.1) master is branch protected prevention pushes to it. > > > > REQ2) git bisect shall always be able to build master of the project at > > every commit. > > DREQ2.a) merges to master may use squash commits from a PR when > > atomic commits are needed to insure REC2. > > DREQ2.b) merges to master may use rebase commits from a PR when NON > > atomic commits will for insure REC2. > > > > REQ3) Submissions shall be PRs against branches typically master. But PR > > shall be accepted against other branches. > > (i.e netlink_crypto) > > REQ3.1) naming conventions shall reflect lineage: > > REQ3.1.a) naming conventions of branches shall be in the form > > <root>_<activity> > > master_pr-add_imxrt20, netlink_crypto-pr-bugfix_AES > > REQ3.1.b) submissions affecting multiple repos shall use the same > > branches name on all repos. > > DREQ3.1.b.1) CI shall test multiple repos by branch name > > > > I would like to loosen up the branch naming requirements, it will make it > harder for people to contribute little things coming from the "GitHub" > world, it's not something I see too much outside of the workplace. Also the > generated branches on GitHub from a PR are using the ids. I'm not trying > to bring tooling in, but I think we should be aware of this and I think it > brings minimal gain. I would be more in favor of the title or body of a PR > doing the linking if we really need the standard to link things together. > We need to be very sensitive to increases in complexity or we will loose > new contributors. > > > > > > > REQ4) committer may collaborate on branches. > > > > REC5) While PR's are preferred, patches may be accepted. > > DREC5.1) Committers receiving patches shall apply them to a new branch > > (per REQ3) and open a PR. > > REC5.1) Committers shall attribute work to the person submitting patch > > > > REC6) All PR requires a review. > > DREC6.1) the project shall publish a list of subject experts > > REC6.1) Request for review shall be made via email to subject experts or > > PPMC. > > REC6.1.1) Multiple reviewers shall be required on OS internals. > > REC6.1.2) Multiple reviewers may be required on NON OS internals. > > > > > > David > > > The rest sounds good. I would say let's start minimal and work up if we > find quality or complexity issues. > > --Brennan > The purpose was accommodating the "repos must be on the ASF infrastructure edict"[1] . Which I believe, please correct me if I am wrong, is pure git??? Therefore I was removing the dependency of githubs features on the work flow. The only way I know how to do this in pure git is: by tag, branch name or SHAL Since we can not use strike out in this environment: Would you be ok with adding your edits in a diff like form? I.e. -REQ3.1) naming conventions shall reflect lineage: +REQ3.1) naming conventions may reflect lineage: [1] mentor's email re:50 years support and how the internet changes Also having to ignore github workfow for the sake of only being top down herein would not be my approach, but I am tying to accommodate everyone input. David
