You would like te see some REQuirements would be addressed by some DevOps thoughts.. but C/C++ are still challenging here. And then the principle: automate where you can!
( https://www.google.nl/amp/s/devops.com/devops-challenges-c-c-projects/amp/) Also one would like that the code to be tested (also hacktesting) through something like SonarCube. Release gates, Ring based deployments, DTAP, Feature Flags, etc... all ideas to use or to look at? Nuttx in the Cloud? Ben Verstuurd vanaf mijn iPhone > Op 21 dec. 2019 om 08:56 heeft Brennan Ashton <bash...@brennanashton.com> het > volgende geschreven: > > 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
