+1 I agree that dev or develop or development is a better name. I just submitted to "stage" because I was doing a test.
On Saturday, December 21, 2019, David Sidrane <david.sidr...@nscdg.com> wrote: > +1 > > -----Original Message----- > From: Brennan Ashton [mailto:bash...@brennanashton.com] > Sent: Saturday, December 21, 2019 9:30 AM > To: dev@nuttx.apache.org > Subject: Re: [CALL for TOP Down workflow Requirements] > > +1 to this. No ci yet so everything "passes" and just gets the commiter > review. We can define more later as needed > > On Sat, Dec 21, 2019, 8:44 AM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > >> Can we simplify the workflow to avoid creating so many temp branching >> in the official repo: >> 1.User submit PR against the master >> 2.Run style, build and test through CI >> 3.Review and comment PR by committer >> 4.Merge PR into master if all check pass >> User may have to repeat step 1 to 3 several time before PR finally accept. >> Note 1: step 2 may be done by committer manually before the tool is ready. >> Note 2: we can refine how many approvement is required before PR can be >> merge. >> If user send patch to dev@nuttx.apache.org instead, one of committer >> need convert the patch to PR by the same process too. >> If there has a big feature development, committer could create a >> branch for that after voting in dev list, but the same process should >> apply to this branch like master. >> Actually, this process is almost same as bitbucket or github, many >> developer is already familiar with it: >> >> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests >> The major difference from David's is that no any temp PR branch is >> created in the official repo. >> >> Thanks >> Xiang >> >> On Sat, Dec 21, 2019 at 8:36 PM Gregory Nutt <spudan...@gmail.com> wrote: >> > >> > This is the mantra we must always follow "support what you users want." >> > Stay focused on the needs and convenience of the end-user. Always good >> > advice. If there are complexities dependencies, we should quantine >> > those complexities and dependencies inside the test architecture. We >> > give the end-user maximal flexibility in all things. >> > >> > Businesses fail that don't listen tho their customers. We will also >> > fail if we do not listen. >> > >> > On 12/21/2019 2:59 AM, Justin Mclean wrote: >> > > Hi, >> > > >> > >> 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??? >> > > Most(?) use git, some also use svn, there might be a couple that still >> use cvs. Use of GitHub is not a requirement, but may be convenient.My >> advice be flexible and support what you users want. >> > > >> > > Thanks, >> > > Justin >> > > >> > > >> > >> >
