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
