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