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 > > > > >
