OK, confirmed. You are thinking we are like a company, but actually, we are not.
We are from all around the world and there are no way to force others to do works for you. If this PR is opened by you, then it is your duty to finish it. No one else will touch it except review and comment, unless you explicitly say that you can not finish the work, and committers will close your PR and open a new one based on your patch. And usually for a company which contribute to an open source project, the people there will maintain an in house or open source repo of the project, and they are free to use any workflow they like, and once they are don3, then upstream the things to the official open source repo. So I think, you can maintain another repo, with your PX4 folks, to use the workflow you like, and then upstream. And finally, I still suggest that, open an issue before you want to do something. If you want others to know you are doing something, it is your duty to let others know, not other’s duty to find out what you are doing. And you even do not want to share your thoughts before writing the code? Especially for a big feature, you even do not have a design doc first? Still, not every contributors are committers, they do not have the permission to create branches. How can they let others know they are working on something? Open an issue or send an email to the mailing list right? And usually, the contributor set is much larger than the committer set for a project in ASF, so do not always stand at the position with committer to think of the workflow. Thank you very much. David Sidrane <david.sidr...@nscdg.com>于2019年12月26日 周四23:51写道： > >Why I have to visit every fork to see what is happening in the project? I > just need to check the PRs and issues. > > Because before a Branch becomes a PR you will not know it is a Work in > Progress (WIP) > > > Open a issue before you do this please? > > You could but, because it is not an issue that carries the wrong messge. > How > about it goes on the project board in Github. In the repo [1] > > > What do you mean by 'help get in a PR'? > > I work from 2:00 AM PST until 4:00 PM - I tell my team what is left at the > end of my day and they pick up the work, push commits to the branch to > finish the PR > From 4:00 PM until 2:00 AM. To get the PR into master. We also yes > XXXX/Tests to thell them the PR is ready (in our case to Fly) and they > test > and put results in PR > BUT they can also fix something, if need be, and PUSH commits. > No one is blocked and it is a team effort. > > [1] > > https://www.google.com/search?q=how+to+use+GitHub+project+boards&gs_ivs=1#tts=0 > David > > -----Original Message----- > From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] > Sent: Thursday, December 26, 2019 7:21 AM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications on > workflow (was RE: Single Committer) > > 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 > > > > > > > > > >
