David Sidrane <david.sidr...@nscdg.com> 于2019年12月26日周四 下午10:06写道：
> >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? > Why I have to visit every fork to see what is happening in the project? I just need to check the PRs and issues. > > 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. Open a issue before you do this please? > 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. > What do you mean by '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 > > > > > >
