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
