On Fri, Dec 27, 2019 at 10:59 PM David Sidrane <david.sidr...@nscdg.com> wrote: > > Hi Greg, > > I have used Bit bucket and Github and others SCM. I have had more positive > Github experiences > > For me Github has always been a better tool except for the killer feature on > BB of meld like diff. > > I am not working against anyone. I am trying to share what I know about GH, > the mistakes I have made with it and do not want to repeat. > > I do not want to limit anyone's ability to do their work their way [GREEN > and CLEAN] > > Can we all agree: That we do not want a github NOOB to define a github work > flow? > Can we all agree: That we do not want a patch NOOB to define a patch work > flow? > > > > I don't know if Bitbucket supported changing the base of a PR like github > > does. But PRs were a nightmare in that > > environment. I think they will work better for us because we have more > > process in place to deal with them. > > >When you are set up to handle PRs they are sweet. > > If we are using github, yes they are. The argument about pr braches in the > repo is pointless. > > Look at the website repos. Look what github does for a committer vs a > contributor. > > Committer - 2 options commit to master or branch in it the repo
Even committer shouldn't modify anything inside official repo without the review process. Committer can merge patch just because the patch pass all workflow criteria. Committer can create branch just because the workflow allow this for some special case(to be discussed). Committer shouldn't abuse his/her power inside official repo just because he/she like to do so. Committer just has one option fork, committer's patch need pass through the same workflow just like the contributor. > Contributor - fork is created. > > When I (as a committer) did a PR via the web UI - which is 100% appropriate > for what it was doing. > > Notice what happened in the repo. Yes, you manually create a branch in official repo without any review process. > See https://github.com/apache/incubator-nuttx-website/branches > > Now do you see why the argument makes sense? > No, since the normal contributor even don't have right to modify anything in official repo. Only committer can hit this issue, you just abuse the committer power. This also demonstrate PX4 workflow encourage people modify the official repo directly just like local fork, I don't think it's a good habit. > Are we going to prohibit this? Think about the ramification. We as > committers will not be able to use the UI when it makes sense. Of course, we should prohibit any modification which doesn't pass the review process like this enter the repo. You can do anything in your fork with UI, but shouldn't mess up the official repo. Many people will sync up with the official repo, any partial or stale work just make the newbie confusion. > > David > > -----Original Message----- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Friday, December 27, 2019 6:27 AM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications on > workflow (was RE: Single Committer) > > Hi, Nathan, > > I remember promising to help you with the workflow document a few days > ago. I am having a little trouble following your outline. Fleshing it > out a little more would probably be helpful to keep us on track. > > Anyway... I did make some first small changes today and I am addressing > this particular topic. Please review. > > > Option 3: For those who do not use git or have git at all, how to get > > changes based on a release to us. Greg can hopefully enlighten us as to > > how > > those customers are currently doing that (are they just zipping their > > entire nuttx tree and sending it? are they using some other > > patch-generating program? what?). Once we know, we document exactly what > > to > > do. > > I have accepted changes in most any form that people want to send them > to me. But never while zipped trees. I have no idea what I would do > with that. For small changes, it is the content that matters, not so > much the form. I have accepted emails just indicating in discussion one > or two line changes. I don't like those very much but I have accepted them. > > Form does matter for larger changes. Some people send diffs generated > with the Linux command line 'diff -r ' command. Those work fine. GIT > patches work too. No one has sent a 'git request-pull' but I suppose > you will deal with that as with a patch. Basically diffs, patches, and > textual pull requests are all the same thing just with varying amounts > of metadata. > > For me, PRs were less used. I would get 20 patches per each PR. I did > not like to accept PRs in the old Bitbucket repositories because they > went directly to master which is not a good practice. I did not have a > development branch and I don't know if Bitbucket supported changing the > base of a PR like github does. But PRs were a nightmare in that > environment. I think they will work better for us because we have more > process in place to deal with them. > > When you are set up to handle PRs they are sweet. > > > When any of those things reach us (by PR or email) we, the committers, do > > whatever is necessary to process them through accept&merge, rework, or > > reject. And again, we have to document for ourselves, the committers, > > exactly how to do that, including git incantations. This is necessary to > > ensure that current committers know what to do and also to lower barriers > > to entry for new committers in the future. > > I think most of us are getting on the same page. DavidS is still the > outlier. David has a lot of knowledge, it would be good if we could get > him on board with the rest of us. We could do so much better if we > worked together. > > Greg
