We can still use GitHub functionality for handling merges etc.. at the end of the day my understanding is the code just has to end up in the repos and synced to Apache's severs.
Not asking to add anything to the proposal just STRIKE REQ3.1 On Sat, Dec 21, 2019, 12:47 AM David Sidrane <davi...@apache.org> wrote: > 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 > > >
