I use GH on all projects that accept it and it is a breeze to work with PR.
I clone the project add my commit and make a PR that can be reviewed and amended depending on the case. BB was harder to use and I felt that the edit and review in place were some of the drawbacks. I agree that with good documentation the PR flow should be easy to handle and review. On Fri, Dec 27, 2019, 16:59 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 > 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. > > See https://github.com/apache/incubator-nuttx-website/branches > > Now do you see why the argument makes sense? > > 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. > > 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 >
