>Then why committers have a different workflow comparing to contributors?
It is the same work flow just different locations and rights. >Why not also create branches in your own forked repo? They can, nothing is stopping them. If their role:contributors that is the only option and the one they should use do not work on master in your own repo keep it in sync with upstream! But it is better because there is a single repo that is the nuttx development not fragmented forks. Do you want to have to visit every fork (before a PR come in) is to see what is happing in the project? Say you look and see a branch master-pr-XYZ - you will ask the owner a PPMC/committer member before you try to add the same thing or ask to work on it with them. You can fork it , duo/master-pr-XYZ, branch it master-pr-XYZ-DZ, - Or you can just push commits to it. Think of the repo like a semaphore and a point of collaboration. Think 24 hr a day hand offs to get a pr in. We can all help get in a PR. David -----Original Message----- From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] Sent: Thursday, December 26, 2019 5:49 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) Then why committers have a different workflow comparing to contributors? Why not also create branches in your own forked repo? David Sidrane <david.sidr...@nscdg.com> 于2019年12月26日周四 下午9:36写道： > Hi Duo, > > > Sure - I just do not which above questions you are referring too, there > are > 67 ? in the post > > I guess this one? > > > For contributors other than committers, especial it is not their > projects, > the repo is not writable to them, and how can they create branches on the > repo? > > Contributors | < committers < PPMC > Rights------|-----------------------------------> > > No Write | Have Write access > Access | Do PR in upstream > Do PR | on Branches > Against | > Upstream| > On | > Branches | > in own | > account | > > > David > > -----Original Message----- > From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] > Sent: Thursday, December 26, 2019 5:10 AM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications > on > workflow (was RE: Single Committer) > > Hey David, could you please explain the above questions a bit? > > Since you want to create PR branches at the official repo, then how could > a > contributor other than committer contribute code? He/she just does not > have > the permission to create a branch. > > Thanks. > > David Sidrane <david.sidr...@nscdg.com> 于2019年12月26日周四 下午4:45写道： > > > Hi Nathan, > > > > This is very aligned with the Apache way - thank you so much for > > thinking > > along these lines. > > > > Please start with git. > > > > Then use the star wars prequel maneuver and feed everything into a > > pipeline > > to git. > > > > You can be the champion of the conversion team and propose development > > of > > zip and rar and svn and USB drive, etc streams to the git repo. > > > > But let's not stick this in front of the job of getting us functional > > while > > at the same time let's all keep this in mind in what we do settle on. > > > > David > > > > -----Original Message----- > > From: Nathan Hartman [mailto:hartman.nat...@gmail.com] > > Sent: Wednesday, December 25, 2019 7:28 PM > > To: dev@nuttx.apache.org > > Subject: Re: Software release life cycle choices could have implications > > on > > workflow (was RE: Single Committer) > > > > On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <jus...@classsoftware.com> > > wrote: > > > > > > People on this list have indicated that they use NuttX released with > > > Apache SVN. > > > > > > The releases are placed in a ASF SVN system to be distributed by the > > > mirror system yes. > > > > > > I think Greg means that users are getting the release tarballs and > > checking > > the code into their own version control system, which may be Subversion, > > Git, proprietary SCM software, etc., or possibly no version control at > all > > (think "installing" NuttX to disk like a library). Therefore the release > > must be SCM-agnostic. (This is why it was a bug when a recent change to > > the > > build system assumed that git was available. I detected that because I > > keep > > NuttX in Subversion.) > > > > For this discussion, it's irrelevant that ASF puts release tarballs in > > Subversion. Users who download the tarballs need not know or care > > because > > from their perspective it's like any other download. Subversion is just > > the > > back end storage for this. > > > > As far as contributors, some may use Git, create a Git clone, and then > > generate either a patch or a PR. But we do *not* want to require using > > Git. > > > > What's not clear to me is how do contributors who *don't* use Git send > > changes to us? Do they use plain 'diff'? Do they use their SCM to > generate > > git-compatible patches? Do they zip up their entire tree? > > > > Also I'd like to emphasize that ANYONE can contribute whether they can > > commit to the NuttX repository or not. What we need to do is document > what > > steps to take, in the Confluence document that we are working on right > > now. > > And we want everyone who is interested to participate so that our > workflow > > will be a product of the whole community. You'll find it much easier to > > adopt the workflow if you helped create it!!! > > > > Thanks, > > Nathan > > >
