Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
This sounds like it was... clone the repo to local. Do our thing making a feature branch.. commit to our own private repo ... Send patch (format patch) in (after nxstyle, indent, etc and README addition) and let it reviewed by sending it to central channel (was Google Group) and checkout locally to master, pull the latest patches from origin/master and do another feature... same proces again. Ben Verstuurd vanaf mijn iPhone > Op 27 dec. 2019 om 21:28 heeft Nathan Hartman het > volgende geschreven: > > On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao > wrote: >>> On Fri, Dec 27, 2019 at 10:59 PM David Sidrane >>> wrote: >>> 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. > > Exactly. > > Any changes you want to make (whether you are a committer or not): > * If you are using GitHub, make a fork, make your changes in your > fork, open a PR. > * If you are using git, make a clone, make your changes in your clone, > send a 'git request-pull' or 'git format-patch'. > * If you are using no SCM / other SCM, get the release tarball, make > your changes, produce a patch. > > Committers are not allowed to bypass the above and put stuff directly > in the repo without going through the same process and review as > everyone else. > > Nathan
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
+1Singin' to choir!Sent from my Samsung Galaxy smartphone. null
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
this is a simple workflow that can fit everybody +1 On Fri, Dec 27, 2019, 22:28 Nathan Hartman wrote: > On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao > wrote: > > On Fri, Dec 27, 2019 at 10:59 PM David Sidrane > wrote: > > > 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. > > Exactly. > > Any changes you want to make (whether you are a committer or not): > * If you are using GitHub, make a fork, make your changes in your > fork, open a PR. > * If you are using git, make a clone, make your changes in your clone, > send a 'git request-pull' or 'git format-patch'. > * If you are using no SCM / other SCM, get the release tarball, make > your changes, produce a patch. > > Committers are not allowed to bypass the above and put stuff directly > in the repo without going through the same process and review as > everyone else. > > Nathan >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao wrote: > On Fri, Dec 27, 2019 at 10:59 PM David Sidrane > wrote: > > 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. Exactly. Any changes you want to make (whether you are a committer or not): * If you are using GitHub, make a fork, make your changes in your fork, open a PR. * If you are using git, make a clone, make your changes in your clone, send a 'git request-pull' or 'git format-patch'. * If you are using no SCM / other SCM, get the release tarball, make your changes, produce a patch. Committers are not allowed to bypass the above and put stuff directly in the repo without going through the same process and review as everyone else. Nathan
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Fri, Dec 27, 2019 at 10:59 PM David Sidrane 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
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
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 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,
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Again, think of you are a contributor, not a commiter. Not all contributors are committers, you should not use a different (official) workflow comparing to them. That's my point. Everything falls into place neatly when you consider the workflow from the point of view of the NuttX end-user / contributor.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Again, think of you are a contributor, not a commiter. Not all contributors are committers, you should not use a different (official) workflow comparing to them. That's my point. David Sidrane 于2019年12月27日周五 下午10:59写道: > 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 >
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
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
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Fri, Dec 27, 2019 at 9:26 AM Gregory Nutt wrote: > 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. I just saw the changes in the email notification. Thanks so much for helping with that!! It looks good and I will review more carefully soon. Also I'll flesh out the outline more. Unfortunately it might take me until Sunday to do it, but I'll work on it as soon as I can. Thanks again for your help! Nathan
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
>I do not know what is the problem for receiving patch from email. Obviously most people will just use git and GitHub but providing another way is also fine? It is not have a problem with the project taking patches. It is just not the ONLY option. > I do not fully get what is the point of your story as I'm not good at reading English stories but if you mean that people should move on to new things, think of Amish. Amish ROFLMAO[1] I am sorry if it does not read well. But I think you got it! Let's embrace it, but not force it. [1] https://en.wikipedia.org/wiki/ROFLMAO -Original Message- From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] Sent: Friday, December 27, 2019 6:16 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) I do not know what is the problem for receiving patch from email. Obviously most people will just use git and GitHub but providing another way is also fine? I do not fully get what is the point of your story as I'm not good at reading English stories but if you mean that people should move on to new things, think of Amish. Thanks. David Sidrane 于2019年12月27日周五 下午9:26写道: > Nathan, > > I am not sure if this is a terminology issue or just being new to github. > (I > feel you. We have all been there!) > > Where do they submit the PR from? > > > https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo > > The only other option is to email patches. > > I do not have any expertise with patches in git other than I can run ' git > format-patch ' > > Can anyone tell me what repo, what branch the following is to/from and > where > it should be applied to? > > From 2d7920055f96f5734d5166e2c58daa16c6dff2f5 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Beat=20K=C3=BCng?= > Date: Thu, 28 Nov 2019 13:08:28 +0100 > Subject: [PATCH 01/19] [BACKPORT] fix stm32h7x3xx_dmamux.h: add missing > underscore to defines > > --- > .../src/stm32h7/hardware/stm32h7x3xx_dmamux.h | 140 +- > 1 file changed, 70 insertions(+), 70 deletions(-) > > diff --git a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > index 7c1f575a86..6c94addc31 100644 > --- a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > +++ b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > @@ -276,50 +276,50 @@ > > > PRs add rich content and context (what branch this applies to at a > minimum)- > that is why they are today's "best practices" > > I would ask all of us to think about new tools[1] and not be doing things > just because[2] > > [1] https://quoteinvestigator.com/2014/05/08/hammer-nail/ > [2] > > https://lists.apache.org/thread.html/98ddb6fcf5a744f3b65f81d850cb535764f16fa207fd883c557fbf4f%40%3Cdev.nuttx.apache.org%3E > > David > > > > -Original Message----- > From: Nathan Hartman [mailto:hartman.nat...@gmail.com] > Sent: Thursday, December 26, 2019 7:34 PM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications > on > workflow (was RE: Single Committer) > > On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) > wrote: > > > Yes, feature branch is another story, but I still need to say that, we > > should not just exclude normal contributors. They do not have the > > permission to push to a feature branch either... > > > There is no problem here. Anyone can clone the repo, work on the feature > branch, and submit PR or patch for the upstream feature branch. >
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
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
+1 I agree with all that you have said. I would just add the WHY. Let's not teach bad habits (HAM Story) Yes document them all and describe why fall a back may be needed. We might even want to rate them as preferred and acceptable (Just like the NuttX Coding Standard document does) David -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Friday, December 27, 2019 6:01 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) On Fri, Dec 27, 2019 at 8:26 AM David Sidrane wrote: > Nathan, > > I am not sure if this is a terminology issue or just being new to github. > (I > feel you. We have all been there!) > > Where do they submit the PR from? > > > https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo > > The only other option is to email patches. > > I do not have any expertise with patches in git other than I can run ' git > format-patch ' > > Can anyone tell me what repo, what branch the following is to/from and > where > it should be applied to? > > (snip) > > PRs add rich content and context (what branch this applies to at a > minimum)- > that is why they are today's "best practices" GitHub is great, but as Justin points out some people cannot use it, and as Greg points out, we need to be considerate of ALL users, it's in the INVIOLABLES. So we must support non-GitHub-based contributions regardless of what we do internally within the project. In addition to 'git format-patch' there is also 'git request-pull'. All we need to do in our Workflow is to document exactly how a contributor gets changes to us, and we have to provide 3 options: Option 1: A GitHub pull request Option 2: Email a pull request to dev@ using git request-pull (and we have to document exactly what sequence of git incantations to use) 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. 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. The more committers we have and the easier we make it for committers to succeed, the stronger the project will be and the more its longevity is ensured. Nathan
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
I do not know what is the problem for receiving patch from email. Obviously most people will just use git and GitHub but providing another way is also fine? I do not fully get what is the point of your story as I'm not good at reading English stories but if you mean that people should move on to new things, think of Amish. Thanks. David Sidrane 于2019年12月27日周五 下午9:26写道: > Nathan, > > I am not sure if this is a terminology issue or just being new to github. > (I > feel you. We have all been there!) > > Where do they submit the PR from? > > > https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo > > The only other option is to email patches. > > I do not have any expertise with patches in git other than I can run ' git > format-patch ' > > Can anyone tell me what repo, what branch the following is to/from and > where > it should be applied to? > > From 2d7920055f96f5734d5166e2c58daa16c6dff2f5 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Beat=20K=C3=BCng?= > Date: Thu, 28 Nov 2019 13:08:28 +0100 > Subject: [PATCH 01/19] [BACKPORT] fix stm32h7x3xx_dmamux.h: add missing > underscore to defines > > --- > .../src/stm32h7/hardware/stm32h7x3xx_dmamux.h | 140 +- > 1 file changed, 70 insertions(+), 70 deletions(-) > > diff --git a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > index 7c1f575a86..6c94addc31 100644 > --- a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > +++ b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h > @@ -276,50 +276,50 @@ > > > PRs add rich content and context (what branch this applies to at a > minimum)- > that is why they are today's "best practices" > > I would ask all of us to think about new tools[1] and not be doing things > just because[2] > > [1] https://quoteinvestigator.com/2014/05/08/hammer-nail/ > [2] > > https://lists.apache.org/thread.html/98ddb6fcf5a744f3b65f81d850cb535764f16fa207fd883c557fbf4f%40%3Cdev.nuttx.apache.org%3E > > David > > > > -----Original Message- > From: Nathan Hartman [mailto:hartman.nat...@gmail.com] > Sent: Thursday, December 26, 2019 7:34 PM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications on > workflow (was RE: Single Committer) > > On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) > wrote: > > > Yes, feature branch is another story, but I still need to say that, we > > should not just exclude normal contributors. They do not have the > > permission to push to a feature branch either... > > > There is no problem here. Anyone can clone the repo, work on the feature > branch, and submit PR or patch for the upstream feature branch. >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Fri, Dec 27, 2019 at 8:26 AM David Sidrane wrote: > Nathan, > > I am not sure if this is a terminology issue or just being new to github. > (I > feel you. We have all been there!) > > Where do they submit the PR from? > > > https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo > > The only other option is to email patches. > > I do not have any expertise with patches in git other than I can run ' git > format-patch ' > > Can anyone tell me what repo, what branch the following is to/from and > where > it should be applied to? > > (snip) > > PRs add rich content and context (what branch this applies to at a > minimum)- > that is why they are today's "best practices" GitHub is great, but as Justin points out some people cannot use it, and as Greg points out, we need to be considerate of ALL users, it's in the INVIOLABLES. So we must support non-GitHub-based contributions regardless of what we do internally within the project. In addition to 'git format-patch' there is also 'git request-pull'. All we need to do in our Workflow is to document exactly how a contributor gets changes to us, and we have to provide 3 options: Option 1: A GitHub pull request Option 2: Email a pull request to dev@ using git request-pull (and we have to document exactly what sequence of git incantations to use) 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. 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. The more committers we have and the easier we make it for committers to succeed, the stronger the project will be and the more its longevity is ensured. Nathan
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Nathan, I am not sure if this is a terminology issue or just being new to github. (I feel you. We have all been there!) Where do they submit the PR from? https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo The only other option is to email patches. I do not have any expertise with patches in git other than I can run ' git format-patch ' Can anyone tell me what repo, what branch the following is to/from and where it should be applied to? >From 2d7920055f96f5734d5166e2c58daa16c6dff2f5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beat=20K=C3=BCng?= Date: Thu, 28 Nov 2019 13:08:28 +0100 Subject: [PATCH 01/19] [BACKPORT] fix stm32h7x3xx_dmamux.h: add missing underscore to defines --- .../src/stm32h7/hardware/stm32h7x3xx_dmamux.h | 140 +- 1 file changed, 70 insertions(+), 70 deletions(-) diff --git a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h index 7c1f575a86..6c94addc31 100644 --- a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h +++ b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h @@ -276,50 +276,50 @@ PRs add rich content and context (what branch this applies to at a minimum)- that is why they are today's "best practices" I would ask all of us to think about new tools[1] and not be doing things just because[2] [1] https://quoteinvestigator.com/2014/05/08/hammer-nail/ [2] https://lists.apache.org/thread.html/98ddb6fcf5a744f3b65f81d850cb535764f16fa207fd883c557fbf4f%40%3Cdev.nuttx.apache.org%3E David -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Thursday, December 26, 2019 7:34 PM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) wrote: > Yes, feature branch is another story, but I still need to say that, we > should not just exclude normal contributors. They do not have the > permission to push to a feature branch either... There is no problem here. Anyone can clone the repo, work on the feature branch, and submit PR or patch for the upstream feature branch.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) wrote: > Yes, feature branch is another story, but I still need to say that, we > should not just exclude normal contributors. They do not have the > permission to push to a feature branch either... There is no problem here. Anyone can clone the repo, work on the feature branch, and submit PR or patch for the upstream feature branch.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Yes, feature branch is another story, but I still need to say that, we should not just exclude normal contributors. They do not have the permission to push to a feature branch either... Yes, and that is basically what is said at that reference too. We need to squash this notion of an uninhibited, unfettered code development like a bug.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Yes, feature branch is another story, but I still need to say that, we should not just exclude normal contributors. They do not have the permission to push to a feature branch either... Gregory Nutt 于2019年12月27日 周五07:52写道: > > > 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. > > I believe that any un-authorized, un-approved, un-reviewed writes to the > repository should never be permitted by anyone unless it is in full > compliance with the work flow requirements. All development is in the > public eye and subject to review and comment from the PPMC and the whole > world. > > But I do think we have not discussed how collaborative feature branches > should work under the workflow requirements. That is really what we are > talking about here. I made an initial stab at feature branch > requirements in the last comment at > > https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton > under "*Extended Development on a Feature Branch*" > > Greg* > * > >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
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. I believe that any un-authorized, un-approved, un-reviewed writes to the repository should never be permitted by anyone unless it is in full compliance with the work flow requirements. All development is in the public eye and subject to review and comment from the PPMC and the whole world. But I do think we have not discussed how collaborative feature branches should work under the workflow requirements. That is really what we are talking about here. I made an initial stab at feature branch requirements in the last comment at https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton under "*Extended Development on a Feature Branch*" Greg* *
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
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 于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 > /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 于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: Si
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
>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 /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 于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 于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 于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. >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
David Sidrane 于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 于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 于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. > > &
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? 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? 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. 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. 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 于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 于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 > > 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 > > fr
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On 12/26/2019 7:49 AM, 张铎(Duo Zhang) wrote: ... Duo should also have access to any external, third party repositories for workflow development. He has also offered to contribute to the NuttX workflow in the past.
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 于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 于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 > > 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 > > >
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
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 于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 > 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 >
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 于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 > 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 >
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
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 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
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 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
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
As long as you stick to git only features you can have everyone work on it, so branch bases workflow would be best. You can still use GitHub only features but just don’t make them compulsory. WRONG! Not also that some more advanced features or options for GItHub that have been discussed here e.g admin access, adding bots may or may not be possible under the ASF. Infra is the admin of all repo and they need to ensure that we know who has contributed code (which generally means bots can’t have write access)and that git history can not be altered. The majority of users do not use GIT at all. NuttX distributions are SCM neutral (all GIT information has been used). People on this list have indicated that they use NuttX released with Apache SVN. I am are of corporation that use proprietary SCMs with NuttX releases. So the whole assumption is wrong. Assume that the NuttX user does not use GIT, does not have GIT, and does not keep NuttX released under GIT control. Nothing in the workflow must ever make that decision or we screw a major part of the NuttX user base. Most companies will not user Code due Jour from the GIT repositiies, they use the SCM-independ NuttX releases. Users get get release versions from the repository by checkout out or branching from the Release tag. But the the release tarballs are SCM agnostic. Greg
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Hi, > The majority of users do not use GIT at all. NuttX distributions are SCM > neutral (all GIT information has been used). User and contributors are different (but overlapping) groups, I believe we were talking about contributors here. Users will be using the releases which are available from the project website (via the ASF mirrors) as a downloadable bundle of source and not touch any SCM system. > 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. Thanks, Justin
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
As long as you stick to git only features you can have everyone work on it, so branch bases workflow would be best. You can still use GitHub only features but just don’t make them compulsory. WRONG! Not also that some more advanced features or options for GItHub that have been discussed here e.g admin access, adding bots may or may not be possible under the ASF. Infra is the admin of all repo and they need to ensure that we know who has contributed code (which generally means bots can’t have write access)and that git history can not be altered. The majority of users do not use GIT at all. NuttX distributions are SCM neutral (all GIT information has been used). People on this list have indicated that they use NuttX released with Apache SVN. I am are of corporation that use proprietary SCMs with NuttX releases. So the whole assumption is wrong. Assume that the NuttX user does not use GIT, does not have GIT, and does not keep NuttX released under GIT control. Nothing in the workflow must ever make that decision or we screw a major part of the NuttX user base. Most companies will not user Code due Jour from the GIT repositiies, they use the SCM-independ NuttX releases.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
This page explicitly says ‘your project’. 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? David Sidrane 于2019年12月26日 周四03:18写道: > Hi Duo, > > > What is the well known and documented WF of github? I've never heard > about > >it. Please be specific. > > https://guides.github.com/introduction/flow/ > > All I add on top of the above is the naming to keep it easy for me to > remember where the contributions was from and where it will go. (I have 8+ > remotes) and work on many branches at the same time all for nuttx. > > For this ASF project I would use: > > -pr- > > master-pr-stm32h7_TX_DMA > master-pr-imxrt_bugfixes > > > What do you mean by pr-branches? > > See above link and my naming suggestions. > > >I still do not get your point why you > >stick to create branches in the offical repo? Why not just use your own > >fork? If you need multiple continuous commits to finish a big feature, you > >can open a branch, we call it a 'feature branch'. > > Can you push to my repo? No. Can I push to yours No. > > Let me ask you the counter question: What are you concerns with working in > the projects repo? > > Is it repo hygiene. There are simple rules (guidelines) > > 1) Use clear un ambiguous naming for branches and branch protection. > 2) pr branches when merge get deteted. > 3) Always ask the branch before delete not you own content. > 4) Add a bot it will help > > >And this usually requires more powerful issue tracker system such as JIRA. > > Here is the question I would ask: Why re-invent the wheel or use disjoint > tools (I have used Jira with github - To me, there was not value add that > made it more it compelling, then issues and Project board in github[1]). > > Github issues and PR work so well together and are cross linked > auto-magically. > > [1] > > https://help.github.com/en/github/managing-your-work-on-github/about-project-boards > > > > David > > > -Original Message----- > From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] > Sent: Wednesday, December 25, 2019 6:37 AM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications on > workflow (was RE: Single Committer) > > David Sidrane 于2019年12月25日周三 下午9:55写道: > > > Hi Xiang, > > > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > > Yes, I agree that we shouldn't make the workflow too hard to scare > > > people for contribution. > > > NuttX isn't a new project, it's open source for more than ten years > > > and has a mature workflow, the whole community is already familiar > > > with it. > > > Let me summary the current workflow: > > > 1.User send patch against master to > > > https://groups.google.com/forum/#!forum/nuttx or > > > 2.User send PR against master to > > https://bitbucket.org/nuttx/nuttx/src/master/ > > > 3.Greg review and merge the change to master(with some modification if > > needed) > > > 4.Greg make a official release and create a tag to mark the point > > > every two(or three?) months > > > To "be apache way", the required change is only item 3&4: all > > > committer need involve the reviewing and release process. > > > So, I suggest that we adapter the current workflow with as minimal > > > changes as possible: > > > > The above workflow was in support of a BD model who preferred to use > > patches and refused to use github. (no disrespect intended). The value it > > added was incredible quality (but in reality only in the areas important > > to the BD). At the same time hindered community growth. This has got to > > stop under ASF "Community before code". > > We all have pressure driving our needs to get changes into master. We can > > do this and it does not have to be the old way or no way or even only one > > way. That is too controlling and it hinders Community. > > > > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW > & > > HW group dynamics. He asked us to think about, and ask yourself "How can > I > > add value to any situation?" When thinking from this perspective it > > removes Not Invented Here (NIH) and ego from the thinking. Some times the > > answer is "I can not add value" let the others who can do it and trust > > them. > > > > We have time to fine tune this. But we must keep it moving. > > > > The only thing I am suggestion > &g
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Hi, As long as you stick to git only features you can have everyone work on it, so branch bases workflow would be best. You can still use GitHub only features but just don’t make them compulsory. Not also that some more advanced features or options for GItHub that have been discussed here e.g admin access, adding bots may or may not be possible under the ASF. Infra is the admin of all repo and they need to ensure that we know who has contributed code (which generally means bots can’t have write access)and that git history can not be altered. Thanks, Justin
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
David Sidrane 于2019年12月26日 周四03:18写道: > Hi Duo, > > > What is the well known and documented WF of github? I've never heard > about > >it. Please be specific. > > https://guides.github.com/introduction/flow/ > > All I add on top of the above is the naming to keep it easy for me to > remember where the contributions was from and where it will go. (I have 8+ > remotes) and work on many branches at the same time all for nuttx. > > For this ASF project I would use: > > -pr- > > master-pr-stm32h7_TX_DMA > master-pr-imxrt_bugfixes > > > What do you mean by pr-branches? > > See above link and my naming suggestions. > > >I still do not get your point why you > >stick to create branches in the offical repo? Why not just use your own > >fork? If you need multiple continuous commits to finish a big feature, you > >can open a branch, we call it a 'feature branch'. > > Can you push to my repo? No. Can I push to yours No. Why I need to push to your repo? I just push to my own forked repo and then I can create PR to your repo and you can decide whether to accept the PR. I’ve never created something like pr-branches when contributing to open source projects. And for NuttX, since I’m not a committer, I can not push to the repo directly then I can not contribute to the project? > > Let me ask you the counter question: What are you concerns with working in > the projects repo? Because contributors can not create branches on the repo. They do not have permission. And the project I’ve worked on do not use way either. > > > Is it repo hygiene. There are simple rules (guidelines) > > 1) Use clear un ambiguous naming for branches and branch protection. > 2) pr branches when merge get deteted. > 3) Always ask the branch before delete not you own content. > 4) Add a bot it will help > > >And this usually requires more powerful issue tracker system such as JIRA. > > Here is the question I would ask: Why re-invent the wheel or use disjoint > tools (I have used Jira with github - To me, there was not value add that > made it more it compelling, then issues and Project board in github[1]). Maybe GitHub issue is fine, not sure. Anyway, this is not important. Let’s stop. > > > Github issues and PR work so well together and are cross linked > auto-magically. > > [1] > > https://help.github.com/en/github/managing-your-work-on-github/about-project-boards > > > > David > > > -Original Message----- > From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] > Sent: Wednesday, December 25, 2019 6:37 AM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications on > workflow (was RE: Single Committer) > > David Sidrane 于2019年12月25日周三 下午9:55写道: > > > Hi Xiang, > > > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > > Yes, I agree that we shouldn't make the workflow too hard to scare > > > people for contribution. > > > NuttX isn't a new project, it's open source for more than ten years > > > and has a mature workflow, the whole community is already familiar > > > with it. > > > Let me summary the current workflow: > > > 1.User send patch against master to > > > https://groups.google.com/forum/#!forum/nuttx or > > > 2.User send PR against master to > > https://bitbucket.org/nuttx/nuttx/src/master/ > > > 3.Greg review and merge the change to master(with some modification if > > needed) > > > 4.Greg make a official release and create a tag to mark the point > > > every two(or three?) months > > > To "be apache way", the required change is only item 3&4: all > > > committer need involve the reviewing and release process. > > > So, I suggest that we adapter the current workflow with as minimal > > > changes as possible: > > > > The above workflow was in support of a BD model who preferred to use > > patches and refused to use github. (no disrespect intended). The value it > > added was incredible quality (but in reality only in the areas important > > to the BD). At the same time hindered community growth. This has got to > > stop under ASF "Community before code". > > We all have pressure driving our needs to get changes into master. We can > > do this and it does not have to be the old way or no way or even only one > > way. That is too controlling and it hinders Community. > > > > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW > & > > HW group dynamics. He asked us to think about, and ask yourself "How can > I > > add v
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
That is a great question. I am not the one to answer it. Perhaps one of the people who cannot get to github can answer it for you. David -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Wednesday, December 25, 2019 12:30 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 2:18 PM David Sidrane wrote: > Github issues and PR work so well together and are cross linked > auto-magically. Justin points out that some people cannot use GitHub and Apache strives to include everyone. I have no opposition to using GitHub and the tools and conveniences it offers, but it's important that we all keep conscious of those concerns when designing our processes so that everyone can participate. For example how can a committer accomplish similar tasks with gitbox? Will doing so violate assumptions that any GitHub-based flow depends on? How to mitigate that? Nathan
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Wed, Dec 25, 2019 at 2:18 PM David Sidrane wrote: > Github issues and PR work so well together and are cross linked > auto-magically. Justin points out that some people cannot use GitHub and Apache strives to include everyone. I have no opposition to using GitHub and the tools and conveniences it offers, but it's important that we all keep conscious of those concerns when designing our processes so that everyone can participate. For example how can a committer accomplish similar tasks with gitbox? Will doing so violate assumptions that any GitHub-based flow depends on? How to mitigate that? Nathan
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Hi Duo, > What is the well known and documented WF of github? I've never heard about >it. Please be specific. https://guides.github.com/introduction/flow/ All I add on top of the above is the naming to keep it easy for me to remember where the contributions was from and where it will go. (I have 8+ remotes) and work on many branches at the same time all for nuttx. For this ASF project I would use: -pr- master-pr-stm32h7_TX_DMA master-pr-imxrt_bugfixes > What do you mean by pr-branches? See above link and my naming suggestions. >I still do not get your point why you >stick to create branches in the offical repo? Why not just use your own >fork? If you need multiple continuous commits to finish a big feature, you >can open a branch, we call it a 'feature branch'. Can you push to my repo? No. Can I push to yours No. Let me ask you the counter question: What are you concerns with working in the projects repo? Is it repo hygiene. There are simple rules (guidelines) 1) Use clear un ambiguous naming for branches and branch protection. 2) pr branches when merge get deteted. 3) Always ask the branch before delete not you own content. 4) Add a bot it will help >And this usually requires more powerful issue tracker system such as JIRA. Here is the question I would ask: Why re-invent the wheel or use disjoint tools (I have used Jira with github - To me, there was not value add that made it more it compelling, then issues and Project board in github[1]). Github issues and PR work so well together and are cross linked auto-magically. [1] https://help.github.com/en/github/managing-your-work-on-github/about-project-boards David -Original Message- From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] Sent: Wednesday, December 25, 2019 6:37 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) David Sidrane 于2019年12月25日周三 下午9:55写道: > Hi Xiang, > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > Yes, I agree that we shouldn't make the workflow too hard to scare > > people for contribution. > > NuttX isn't a new project, it's open source for more than ten years > > and has a mature workflow, the whole community is already familiar > > with it. > > Let me summary the current workflow: > > 1.User send patch against master to > > https://groups.google.com/forum/#!forum/nuttx or > > 2.User send PR against master to > https://bitbucket.org/nuttx/nuttx/src/master/ > > 3.Greg review and merge the change to master(with some modification if > needed) > > 4.Greg make a official release and create a tag to mark the point > > every two(or three?) months > > To "be apache way", the required change is only item 3&4: all > > committer need involve the reviewing and release process. > > So, I suggest that we adapter the current workflow with as minimal > > changes as possible: > > The above workflow was in support of a BD model who preferred to use > patches and refused to use github. (no disrespect intended). The value it > added was incredible quality (but in reality only in the areas important > to the BD). At the same time hindered community growth. This has got to > stop under ASF "Community before code". > We all have pressure driving our needs to get changes into master. We can > do this and it does not have to be the old way or no way or even only one > way. That is too controlling and it hinders Community. > > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & > HW group dynamics. He asked us to think about, and ask yourself "How can I > add value to any situation?" When thinking from this perspective it > removes Not Invented Here (NIH) and ego from the thinking. Some times the > answer is "I can not add value" let the others who can do it and trust > them. > > We have time to fine tune this. But we must keep it moving. > > The only thing I am suggestion > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in > the upstream repo.. > What do you mean by pr-branches? I still do not get your point why you stick to create branches in the offical repo? Why not just use your own fork? If you need multiple continuous commits to finish a big feature, you can open a branch, we call it a 'feature branch'. And this usually requires more powerful issue tracker system such as JIRA. > 2) Have the option to use github's well know and document WF > What is the well known and documented WF of github? I've never heard about it. Please be specific. > 3) add branch protection to master > Agree if the branch protection here means disable force push. > > T
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
What is https://codersrank.io/ ? I am not failure with it. Do you have a screen shot that relates to this discussion? -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Wednesday, December 25, 2019 7:58 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) Doesn't do any good at social bragging sites like https://codersrank.io/ On 12/25/2019 9:47 AM, David Sidrane wrote: > Even on a squashed merge there is traceability back to the PR and > therefore > ALL the history will be on the mailing list and publically available on > GH. > > This is why a rebase work flow has to stop after review. (With some > exceptions) but we always attribute to the Authors > > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Wednesday, December 25, 2019 6:44 AM > To: dev@nuttx.apache.org > Subject: Re: Software release life cycle choices could have implications > on > workflow (was RE: Single Committer) > > >> If they are related / dependent on each other, then I think those >> kinds of patchsets should be encapsulated in one branch. > That would work fine provided that the branch is not squashed to > master. That loses authorship of individual contributions.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Doesn't do any good at social bragging sites like https://codersrank.io/ On 12/25/2019 9:47 AM, David Sidrane wrote: Even on a squashed merge there is traceability back to the PR and therefore ALL the history will be on the mailing list and publically available on GH. This is why a rebase work flow has to stop after review. (With some exceptions) but we always attribute to the Authors -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Wednesday, December 25, 2019 6:44 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) If they are related / dependent on each other, then I think those kinds of patchsets should be encapsulated in one branch. That would work fine provided that the branch is not squashed to master. That loses authorship of individual contributions.
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Even on a squashed merge there is traceability back to the PR and therefore ALL the history will be on the mailing list and publically available on GH. This is why a rebase work flow has to stop after review. (With some exceptions) but we always attribute to the Authors -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Wednesday, December 25, 2019 6:44 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) > If they are related / dependent on each other, then I think those > kinds of patchsets should be encapsulated in one branch. That would work fine provided that the branch is not squashed to master. That loses authorship of individual contributions.
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Branch protection https://help.github.com/en/github/administering-a-repository/about-protected-branches About protected branches. Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. Enabling protected branches also allows you to enable other optional checks and requirements, like required status checks and required reviews. About protected branches - GitHub Help https://help.github.com › github › administering-a-repository › about-protect... David -Original Message- From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com] Sent: Wednesday, December 25, 2019 6:37 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) David Sidrane 于2019年12月25日周三 下午9:55写道: > Hi Xiang, > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > Yes, I agree that we shouldn't make the workflow too hard to scare > > people for contribution. > > NuttX isn't a new project, it's open source for more than ten years > > and has a mature workflow, the whole community is already familiar > > with it. > > Let me summary the current workflow: > > 1.User send patch against master to > > https://groups.google.com/forum/#!forum/nuttx or > > 2.User send PR against master to > https://bitbucket.org/nuttx/nuttx/src/master/ > > 3.Greg review and merge the change to master(with some modification if > needed) > > 4.Greg make a official release and create a tag to mark the point > > every two(or three?) months > > To "be apache way", the required change is only item 3&4: all > > committer need involve the reviewing and release process. > > So, I suggest that we adapter the current workflow with as minimal > > changes as possible: > > The above workflow was in support of a BD model who preferred to use > patches and refused to use github. (no disrespect intended). The value it > added was incredible quality (but in reality only in the areas important > to the BD). At the same time hindered community growth. This has got to > stop under ASF "Community before code". > We all have pressure driving our needs to get changes into master. We can > do this and it does not have to be the old way or no way or even only one > way. That is too controlling and it hinders Community. > > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & > HW group dynamics. He asked us to think about, and ask yourself "How can I > add value to any situation?" When thinking from this perspective it > removes Not Invented Here (NIH) and ego from the thinking. Some times the > answer is "I can not add value" let the others who can do it and trust > them. > > We have time to fine tune this. But we must keep it moving. > > The only thing I am suggestion > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in > the upstream repo.. > What do you mean by pr-branches? I still do not get your point why you stick to create branches in the offical repo? Why not just use your own fork? If you need multiple continuous commits to finish a big feature, you can open a branch, we call it a 'feature branch'. And this usually requires more powerful issue tracker system such as JIRA. > 2) Have the option to use github's well know and document WF > What is the well known and documented WF of github? I've never heard about it. Please be specific. > 3) add branch protection to master > Agree if the branch protection here means disable force push. > > This will not EXCLUDE anyone from doing it the OLD way or as you suggest > below. > > > 1.User send patch against master to dev@nuttx.apache.org or > > 2.User send PR against master to > https://github.com/apache/incubator-nuttx > > 3.Committer review and merge the change to master(with some > > modification if needed) > > 4.Committer make a official release and create a tag to mark the point > > every two(or three?) months > > We only need to disscuss how committer review the change and make the > release. > > Since we have two month for the next release, let's focus on the > > review process in this time. > > Here are some questions I have, other may add more: > > a.How many committers need approve the patch before it can merge? > > b.How much time give the committer the chance to say no? > > Once all questions get the resonable answer, we can make a vote. > > If anyone has a new idea(e.g. submodule, dev/pr/release branch, > > backport, LTS) send your proprosal to dev list and let community > > discuss and vote. > > But before the proprosal is accepted by the
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
+1 -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Wednesday, December 25, 2019 6:41 AM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) > Why does the authors matter. There is no reason a patchset or PR needs to > be squashed into a single commit, they just should not be broken along the > way. It does not matter to the project. But it matters very much to some contributors. Especially young or newbie contributors who see this a recognition by the technical community. I have even seen people share there commits proudly in social media. For those of us who have been doing this for a long time, we don't need that recognition (I have around 36,000 commits to the project), but that is not true of others. So I think we need to be respectful of contributors. I believe that we owe contributors of patches to the OS the public recognition that they deserve. Greg
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
-Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Wednesday, December 25, 2019 6:55 AM 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 9:55 PM David Sidrane wrote: > > Hi Xiang, > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > Yes, I agree that we shouldn't make the workflow too hard to scare > > people for contribution. > > NuttX isn't a new project, it's open source for more than ten years > > and has a mature workflow, the whole community is already familiar > > with it. > > Let me summary the current workflow: > > 1.User send patch against master to > > https://groups.google.com/forum/#!forum/nuttx or > > 2.User send PR against master to https://bitbucket.org/nuttx/nuttx/src/master/ > > 3.Greg review and merge the change to master(with some modification if needed) > > 4.Greg make a official release and create a tag to mark the point > > every two(or three?) months > > To "be apache way", the required change is only item 3&4: all > > committer need involve the reviewing and release process. > > So, I suggest that we adapter the current workflow with as minimal > > changes as possible: > > The above workflow was in support of a BD model who preferred to use patches and refused to use github. (no disrespect intended). The value it added was incredible quality (but in reality only in the areas important to the BD). At the same time hindered community growth. This has got to stop under ASF "Community before code". > We all have pressure driving our needs to get changes into master. We can do this and it does not have to be the old way or no way or even only one way. That is too controlling and it hinders Community. > Why is it become BD mode without PR branch? almost github project I contributed before don't create the branch for PR, here are some examples: https://github.com/curl/curl/pull/4756 https://github.com/esnet/iperf/pull/935 https://github.com/OpenAMP/open-amp/pull/184 I was referring to the past. Patches were directly applied to master. Anyone could make the comment and suggestion for PR through github UI directly, I don't think we can't review code without PR branch here. Even PX4 doesn't create the PR branch for each patch, for example: https://github.com/PX4/Firmware/pull/13787 you just send it 19 hours ago which against master but without PR branch. No. That is not the case Note its location the BRANCH is here https://github.com/PX4/Firmware/tree/master_SDIO_pu_fixes > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & HW group dynamics. He asked us to think about, and ask yourself "How can I add value to any situation?" When thinking from this perspective it removes Not Invented Here (NIH) and ego from the thinking. Some times the answer is "I can not add value" let the others who can do it and trust them. > > We have time to fine tune this. But we must keep it moving. > > The only thing I am suggestion > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in the upstream repo.. I don't reject the branch on the official repo: if some big feature need to develop or some modification need involve multiple people, the new branch can be created for that after the disscussion. What I don't like is create the branch for every patch, which just make the process more complicated and mess the official repo. I just count PX4 repo: total 272 branches, 64 branches is old than 1 year, 150 branches is old than 1 month. > 2) Have the option to use github's well know and document WF > 3) add branch protection to master > Yes, before patch merge into master, it should go through the review process documented by the workflow. Of course, as Abdelatif note that we have to bypass the workflow in some special case. [DBS] Even in the extreme case You can still do the correct thing. Create a branch, open a PR and use the ADMIN override to merge it.!! > This will not EXCLUDE anyone from doing it the OLD way or as you suggest below. > > > 1.User send patch against master to dev@nuttx.apache.org or > > 2.User send PR against master to https://github.com/apache/incubator-nuttx > > 3.Committer review and merge the change to master(with some > > modification if needed) > > 4.Committer make a official release and create a tag to mark the point > > every two(or three?) months > > We only need to disscuss how committer review the change and make the release. > > Since we have two month for the next release, let's focus
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Hi Duo, I am sorry I broke my own rule. I should have defined it. BD: Benevolent dictator for life (BDFL) is a title given to a small number of open-source software development leaders, typically project founders who retain the final say in disputes or arguments within the community. On 2019/12/25 14:26:47, 张铎(Duo Zhang) wrote: > Pardon me, what is a BD model? I do not get your point why requiring users > to send a patch or open a PR against master will hindered the community > growth? I was speaking of the past (pre ASF) model and the last few days, Specifically not acting like a team and having PR closed without consideration of taking the commit that was not in dispute that made the tool more useful by adding parse-able output. That does not foster community, it stifles it. > Or you say #3 and #4? These are what we want to change. This 3 & 4? 3.Committer review and merge the change to master(with some modification if needed) (with some modification if needed) - this should only happen on a PR as one separate commit to be traceable. There is nothing more off putting the 250 style changes to a users 2 line PR. The changes I want are to support collaboration in the repo. 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in the upstream repo. This works well for "drive-by PRs". This is the term given to what you described as a PR with value, that Author does not want to take the effort to make changes to do it the best way for the system. We can tag team on getting things like this in. If we do not do this we have to give N committers write access to N committers repos. That does not scale well and will encourage forks. 2) Have the **option*** to use github's well know and document WF Give the people the freedom to work in the most efficient way a person chooses (GREEN and CLEAN)[1] 3) add branch protection to master Avoid any accidents - we are all human. 4.Committer make a official release and create a tag to mark the point every two(or three?) months This is fine, but we will need the process documents to be consistent results. We have time for that. > > Thanks. > > David Sidrane 于2019年12月25日周三 下午9:55写道: > > > Hi Xiang, > > > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > > Yes, I agree that we shouldn't make the workflow too hard to scare > > > people for contribution. > > > NuttX isn't a new project, it's open source for more than ten years > > > and has a mature workflow, the whole community is already familiar > > > with it. > > > Let me summary the current workflow: > > > 1.User send patch against master to > > > https://groups.google.com/forum/#!forum/nuttx or > > > 2.User send PR against master to > > https://bitbucket.org/nuttx/nuttx/src/master/ > > > 3.Greg review and merge the change to master(with some modification if > > needed) > > > 4.Greg make a official release and create a tag to mark the point > > > every two(or three?) months > > > To "be apache way", the required change is only item 3&4: all > > > committer need involve the reviewing and release process. > > > So, I suggest that we adapter the current workflow with as minimal > > > changes as possible: > > > > The above workflow was in support of a BD model who preferred to use > > patches and refused to use github. (no disrespect intended). The value it > > added was incredible quality (but in reality only in the areas important > > to the BD). At the same time hindered community growth. This has got to > > stop under ASF "Community before code". > > We all have pressure driving our needs to get changes into master. We can > > do this and it does not have to be the old way or no way or even only one > > way. That is too controlling and it hinders Community. > > > > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & > > HW group dynamics. He asked us to think about, and ask yourself "How can I > > add value to any situation?" When thinking from this perspective it > > removes Not Invented Here (NIH) and ego from the thinking. Some times the > > answer is "I can not add value" let the others who can do it and trust > > them. > > > > We have time to fine tune this. But we must keep it moving. > > > > The only thing I am suggestion > > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in > > the upstream repo.. > > 2) Have the option to use github's well know and document WF > > 3) add branch protection to master > > > > This will not EXCLUDE anyone from doing it the OLD way or as you suggest > > below. > > > > > 1.User send patch against master to dev@nuttx.apache.org or > > > 2.User send PR against master to > > https://github.com/apache/incubator-nuttx > > > 3.Committer review and merge the change to master(with some > > > modification if needed) > > > 4.Committer make a official release and create a tag to mark the point > > > every two(or three?) months > > > We only need to disscuss how committer review th
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Wed, Dec 25, 2019 at 9:55 PM David Sidrane wrote: > > Hi Xiang, > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > Yes, I agree that we shouldn't make the workflow too hard to scare > > people for contribution. > > NuttX isn't a new project, it's open source for more than ten years > > and has a mature workflow, the whole community is already familiar > > with it. > > Let me summary the current workflow: > > 1.User send patch against master to > > https://groups.google.com/forum/#!forum/nuttx or > > 2.User send PR against master to > > https://bitbucket.org/nuttx/nuttx/src/master/ > > 3.Greg review and merge the change to master(with some modification if > > needed) > > 4.Greg make a official release and create a tag to mark the point > > every two(or three?) months > > To "be apache way", the required change is only item 3&4: all > > committer need involve the reviewing and release process. > > So, I suggest that we adapter the current workflow with as minimal > > changes as possible: > > The above workflow was in support of a BD model who preferred to use patches > and refused to use github. (no disrespect intended). The value it added was > incredible quality (but in reality only in the areas important to the BD). > At the same time hindered community growth. This has got to stop under ASF > "Community before code". > We all have pressure driving our needs to get changes into master. We can do > this and it does not have to be the old way or no way or even only one way. > That is too controlling and it hinders Community. > Why is it become BD mode without PR branch? almost github project I contributed before don't create the branch for PR, here are some examples: https://github.com/curl/curl/pull/4756 https://github.com/esnet/iperf/pull/935 https://github.com/OpenAMP/open-amp/pull/184 Anyone could make the comment and suggestion for PR through github UI directly, I don't think we can't review code without PR branch here. Even PX4 doesn't create the PR branch for each patch, for example: https://github.com/PX4/Firmware/pull/13787 you just send it 19 hours ago which against master but without PR branch. > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & HW > group dynamics. He asked us to think about, and ask yourself "How can I add > value to any situation?" When thinking from this perspective it removes Not > Invented Here (NIH) and ego from the thinking. Some times the answer is "I > can not add value" let the others who can do it and trust them. > > We have time to fine tune this. But we must keep it moving. > > The only thing I am suggestion > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in > the upstream repo.. I don't reject the branch on the official repo: if some big feature need to develop or some modification need involve multiple people, the new branch can be created for that after the disscussion. What I don't like is create the branch for every patch, which just make the process more complicated and mess the official repo. I just count PX4 repo: total 272 branches, 64 branches is old than 1 year, 150 branches is old than 1 month. > 2) Have the option to use github's well know and document WF > 3) add branch protection to master > Yes, before patch merge into master, it should go through the review process documented by the workflow. Of course, as Abdelatif note that we have to bypass the workflow in some special case. > This will not EXCLUDE anyone from doing it the OLD way or as you suggest > below. > > > 1.User send patch against master to dev@nuttx.apache.org or > > 2.User send PR against master to https://github.com/apache/incubator-nuttx > > 3.Committer review and merge the change to master(with some > > modification if needed) > > 4.Committer make a official release and create a tag to mark the point > > every two(or three?) months > > We only need to disscuss how committer review the change and make the > > release. > > Since we have two month for the next release, let's focus on the > > review process in this time. > > Here are some questions I have, other may add more: > > a.How many committers need approve the patch before it can merge? > > b.How much time give the committer the chance to say no? > > Once all questions get the resonable answer, we can make a vote. > > If anyone has a new idea(e.g. submodule, dev/pr/release branch, > > backport, LTS) send your proprosal to dev list and let community > > discuss and vote. > > But before the proprosal is accepted by the community, why we stop to > > use the current workflow and make our work stuck? > > > > Thanks > > Xiang > > > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean > > wrote: > > > > > > Hi, > > > > > > Some observations that might apply. > > > > > > I've used GitFlow on a few projects here at Apache and elsewhere, it does > > > have some downsides, it’s overly complex and confuses beginners > > > (particularly those unfamiliar with g
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
If they are related / dependent on each other, then I think those kinds of patchsets should be encapsulated in one branch. That would work fine provided that the branch is not squashed to master. That loses authorship of individual contributions.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Why does the authors matter. There is no reason a patchset or PR needs to be squashed into a single commit, they just should not be broken along the way. It does not matter to the project. But it matters very much to some contributors. Especially young or newbie contributors who see this a recognition by the technical community. I have even seen people share there commits proudly in social media. For those of us who have been doing this for a long time, we don't need that recognition (I have around 36,000 commits to the project), but that is not true of others. So I think we need to be respectful of contributors. I believe that we owe contributors of patches to the OS the public recognition that they deserve. Greg
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
David Sidrane 于2019年12月25日周三 下午9:55写道: > Hi Xiang, > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > Yes, I agree that we shouldn't make the workflow too hard to scare > > people for contribution. > > NuttX isn't a new project, it's open source for more than ten years > > and has a mature workflow, the whole community is already familiar > > with it. > > Let me summary the current workflow: > > 1.User send patch against master to > > https://groups.google.com/forum/#!forum/nuttx or > > 2.User send PR against master to > https://bitbucket.org/nuttx/nuttx/src/master/ > > 3.Greg review and merge the change to master(with some modification if > needed) > > 4.Greg make a official release and create a tag to mark the point > > every two(or three?) months > > To "be apache way", the required change is only item 3&4: all > > committer need involve the reviewing and release process. > > So, I suggest that we adapter the current workflow with as minimal > > changes as possible: > > The above workflow was in support of a BD model who preferred to use > patches and refused to use github. (no disrespect intended). The value it > added was incredible quality (but in reality only in the areas important > to the BD). At the same time hindered community growth. This has got to > stop under ASF "Community before code". > We all have pressure driving our needs to get changes into master. We can > do this and it does not have to be the old way or no way or even only one > way. That is too controlling and it hinders Community. > > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & > HW group dynamics. He asked us to think about, and ask yourself "How can I > add value to any situation?" When thinking from this perspective it > removes Not Invented Here (NIH) and ego from the thinking. Some times the > answer is "I can not add value" let the others who can do it and trust > them. > > We have time to fine tune this. But we must keep it moving. > > The only thing I am suggestion > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in > the upstream repo.. > What do you mean by pr-branches? I still do not get your point why you stick to create branches in the offical repo? Why not just use your own fork? If you need multiple continuous commits to finish a big feature, you can open a branch, we call it a 'feature branch'. And this usually requires more powerful issue tracker system such as JIRA. > 2) Have the option to use github's well know and document WF > What is the well known and documented WF of github? I've never heard about it. Please be specific. > 3) add branch protection to master > Agree if the branch protection here means disable force push. > > This will not EXCLUDE anyone from doing it the OLD way or as you suggest > below. > > > 1.User send patch against master to dev@nuttx.apache.org or > > 2.User send PR against master to > https://github.com/apache/incubator-nuttx > > 3.Committer review and merge the change to master(with some > > modification if needed) > > 4.Committer make a official release and create a tag to mark the point > > every two(or three?) months > > We only need to disscuss how committer review the change and make the > release. > > Since we have two month for the next release, let's focus on the > > review process in this time. > > Here are some questions I have, other may add more: > > a.How many committers need approve the patch before it can merge? > > b.How much time give the committer the chance to say no? > > Once all questions get the resonable answer, we can make a vote. > > If anyone has a new idea(e.g. submodule, dev/pr/release branch, > > backport, LTS) send your proprosal to dev list and let community > > discuss and vote. > > But before the proprosal is accepted by the community, why we stop to > > use the current workflow and make our work stuck? > > > > Thanks > > Xiang > > > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean > wrote: > > > > > > Hi, > > > > > > Some observations that might apply. > > > > > > I've used GitFlow on a few projects here at Apache and elsewhere, it > does have some downsides, it’s overly complex and confuses beginners > (particularly those unfamiliar with git),tends to create long lived > branches (which are hard to merge), master and develop (or whatever you > call the main two branches) tend to subtly get out of sync over time. > > > > > > You can change the GitHub default branch (you need to ask infra). A > bigger issue with having master / develop and if you don’t merge frequently > is that people don’t think the committers are that active, external people > don't tend to look at activity on the branches. > > > > > > Note that Apache Git/GitHub has some restrictions, we don’t want > history to be rewritten for legal and provenance reasons so a couple of > things you may be used to doing outside of Apache may not be possible. > Squashing commits in some projects tends to be frowned on for this re
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Pardon me, what is a BD model? I do not get your point why requiring users to send a patch or open a PR against master will hindered the community growth? Or you say #3 and #4? These are what we want to change. Thanks. David Sidrane 于2019年12月25日周三 下午9:55写道: > Hi Xiang, > > On 2019/12/25 05:36:14, Xiang Xiao wrote: > > Yes, I agree that we shouldn't make the workflow too hard to scare > > people for contribution. > > NuttX isn't a new project, it's open source for more than ten years > > and has a mature workflow, the whole community is already familiar > > with it. > > Let me summary the current workflow: > > 1.User send patch against master to > > https://groups.google.com/forum/#!forum/nuttx or > > 2.User send PR against master to > https://bitbucket.org/nuttx/nuttx/src/master/ > > 3.Greg review and merge the change to master(with some modification if > needed) > > 4.Greg make a official release and create a tag to mark the point > > every two(or three?) months > > To "be apache way", the required change is only item 3&4: all > > committer need involve the reviewing and release process. > > So, I suggest that we adapter the current workflow with as minimal > > changes as possible: > > The above workflow was in support of a BD model who preferred to use > patches and refused to use github. (no disrespect intended). The value it > added was incredible quality (but in reality only in the areas important > to the BD). At the same time hindered community growth. This has got to > stop under ASF "Community before code". > We all have pressure driving our needs to get changes into master. We can > do this and it does not have to be the old way or no way or even only one > way. That is too controlling and it hinders Community. > > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & > HW group dynamics. He asked us to think about, and ask yourself "How can I > add value to any situation?" When thinking from this perspective it > removes Not Invented Here (NIH) and ego from the thinking. Some times the > answer is "I can not add value" let the others who can do it and trust > them. > > We have time to fine tune this. But we must keep it moving. > > The only thing I am suggestion > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in > the upstream repo.. > 2) Have the option to use github's well know and document WF > 3) add branch protection to master > > This will not EXCLUDE anyone from doing it the OLD way or as you suggest > below. > > > 1.User send patch against master to dev@nuttx.apache.org or > > 2.User send PR against master to > https://github.com/apache/incubator-nuttx > > 3.Committer review and merge the change to master(with some > > modification if needed) > > 4.Committer make a official release and create a tag to mark the point > > every two(or three?) months > > We only need to disscuss how committer review the change and make the > release. > > Since we have two month for the next release, let's focus on the > > review process in this time. > > Here are some questions I have, other may add more: > > a.How many committers need approve the patch before it can merge? > > b.How much time give the committer the chance to say no? > > Once all questions get the resonable answer, we can make a vote. > > If anyone has a new idea(e.g. submodule, dev/pr/release branch, > > backport, LTS) send your proprosal to dev list and let community > > discuss and vote. > > But before the proprosal is accepted by the community, why we stop to > > use the current workflow and make our work stuck? > > > > Thanks > > Xiang > > > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean > wrote: > > > > > > Hi, > > > > > > Some observations that might apply. > > > > > > I've used GitFlow on a few projects here at Apache and elsewhere, it > does have some downsides, it’s overly complex and confuses beginners > (particularly those unfamiliar with git),tends to create long lived > branches (which are hard to merge), master and develop (or whatever you > call the main two branches) tend to subtly get out of sync over time. > > > > > > You can change the GitHub default branch (you need to ask infra). A > bigger issue with having master / develop and if you don’t merge frequently > is that people don’t think the committers are that active, external people > don't tend to look at activity on the branches. > > > > > > Note that Apache Git/GitHub has some restrictions, we don’t want > history to be rewritten for legal and provenance reasons so a couple of > things you may be used to doing outside of Apache may not be possible. > Squashing commits in some projects tends to be frowned on for this reasons. > Similarly we need to know the author of any change. > > > > > > Thanks, > > > Justin > > > > > > > > > > David >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Hi Xiang, On 2019/12/25 05:36:14, Xiang Xiao wrote: > Yes, I agree that we shouldn't make the workflow too hard to scare > people for contribution. > NuttX isn't a new project, it's open source for more than ten years > and has a mature workflow, the whole community is already familiar > with it. > Let me summary the current workflow: > 1.User send patch against master to > https://groups.google.com/forum/#!forum/nuttx or > 2.User send PR against master to https://bitbucket.org/nuttx/nuttx/src/master/ > 3.Greg review and merge the change to master(with some modification if needed) > 4.Greg make a official release and create a tag to mark the point > every two(or three?) months > To "be apache way", the required change is only item 3&4: all > committer need involve the reviewing and release process. > So, I suggest that we adapter the current workflow with as minimal > changes as possible: The above workflow was in support of a BD model who preferred to use patches and refused to use github. (no disrespect intended). The value it added was incredible quality (but in reality only in the areas important to the BD). At the same time hindered community growth. This has got to stop under ASF "Community before code". We all have pressure driving our needs to get changes into master. We can do this and it does not have to be the old way or no way or even only one way. That is too controlling and it hinders Community. My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & HW group dynamics. He asked us to think about, and ask yourself "How can I add value to any situation?" When thinking from this perspective it removes Not Invented Here (NIH) and ego from the thinking. Some times the answer is "I can not add value" let the others who can do it and trust them. We have time to fine tune this. But we must keep it moving. The only thing I am suggestion 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in the upstream repo.. 2) Have the option to use github's well know and document WF 3) add branch protection to master This will not EXCLUDE anyone from doing it the OLD way or as you suggest below. > 1.User send patch against master to dev@nuttx.apache.org or > 2.User send PR against master to https://github.com/apache/incubator-nuttx > 3.Committer review and merge the change to master(with some > modification if needed) > 4.Committer make a official release and create a tag to mark the point > every two(or three?) months > We only need to disscuss how committer review the change and make the release. > Since we have two month for the next release, let's focus on the > review process in this time. > Here are some questions I have, other may add more: > a.How many committers need approve the patch before it can merge? > b.How much time give the committer the chance to say no? > Once all questions get the resonable answer, we can make a vote. > If anyone has a new idea(e.g. submodule, dev/pr/release branch, > backport, LTS) send your proprosal to dev list and let community > discuss and vote. > But before the proprosal is accepted by the community, why we stop to > use the current workflow and make our work stuck? > > Thanks > Xiang > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean > wrote: > > > > Hi, > > > > Some observations that might apply. > > > > I've used GitFlow on a few projects here at Apache and elsewhere, it does > > have some downsides, it’s overly complex and confuses beginners > > (particularly those unfamiliar with git),tends to create long lived > > branches (which are hard to merge), master and develop (or whatever you > > call the main two branches) tend to subtly get out of sync over time. > > > > You can change the GitHub default branch (you need to ask infra). A bigger > > issue with having master / develop and if you don’t merge frequently is > > that people don’t think the committers are that active, external people > > don't tend to look at activity on the branches. > > > > Note that Apache Git/GitHub has some restrictions, we don’t want history to > > be rewritten for legal and provenance reasons so a couple of things you may > > be used to doing outside of Apache may not be possible. Squashing commits > > in some projects tends to be frowned on for this reasons. Similarly we need > > to know the author of any change. > > > > Thanks, > > Justin > > > > > David
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
> For me on HBase, this depends on lots of things. If it is only a typo then > I will merge it immediately. If it is a simple bug fix, I will wait a bit > long and if some committers are familiar with this part, I will try to ask > their opinions. And if this is a very big new feature, sometimes people > will even send an email to the mailing list to attract more reviews before > committing. Some ASF projects define Obvious Fixes and Emergency Merges. Obvious Fixes are the like of typos, cosmetics, CS violations that slipped by the review, etc. Emergency merges are where nobody is around to review the change and some subsystem is broken and needs it. These can be merged by a committer without waiting for another review. Obvious fixes can be frequent during the release branch period. On Wed, Dec 25, 2019 at 12:59 PM 张铎(Duo Zhang) wrote: > > What I mean is that, nobody wants its patch to be reverted right? So you > will find a proper way to archive this. There is no straight forward rule > on how much time to wait. > > For me on HBase, this depends on lots of things. If it is only a typo then > I will merge it immediately. If it is a simple bug fix, I will wait a bit > long and if some committers are familiar with this part, I will try to ask > their opinions. And if this is a very big new feature, sometimes people > will even send an email to the mailing list to attract more reviews before > committing. > > So in general, I do not think there is an one-for-all rule. NuttX community > has its own culture, and the ‘rule’ will be set up though practice. > > Thanks. > > Xiang Xiao 于2019年12月25日 周三19:50写道: > > > On Wed, Dec 25, 2019 at 2:30 PM 张铎(Duo Zhang) > > wrote: > > > > > > Xiang Xiao 于2019年12月25日周三 下午1:36写道: > > > > > > > Yes, I agree that we shouldn't make the workflow too hard to scare > > > > people for contribution. > > > > NuttX isn't a new project, it's open source for more than ten years > > > > and has a mature workflow, the whole community is already familiar > > > > with it. > > > > Let me summary the current workflow: > > > > 1.User send patch against master to > > > > https://groups.google.com/forum/#!forum/nuttx or > > > > 2.User send PR against master to > > > > https://bitbucket.org/nuttx/nuttx/src/master/ > > > > 3.Greg review and merge the change to master(with some modification if > > > > needed) > > > > 4.Greg make a official release and create a tag to mark the point > > > > every two(or three?) months > > > > To "be apache way", the required change is only item 3&4: all > > > > committer need involve the reviewing and release process. > > > > So, I suggest that we adapter the current workflow with as minimal > > > > changes as possible: > > > > 1.User send patch against master to dev@nuttx.apache.org or > > > > 2.User send PR against master to > > https://github.com/apache/incubator-nuttx > > > > 3.Committer review and merge the change to master(with some > > > > modification if needed) > > > > 4.Committer make a official release and create a tag to mark the point > > > > every two(or three?) months > > > > We only need to disscuss how committer review the change and make the > > > > release. > > > > Since we have two month for the next release, let's focus on the > > > > review process in this time. > > > > Here are some questions I have, other may add more: > > > > a.How many committers need approve the patch before it can merge? > > > > > > > Usually one committer is enough, the only different is that, if the patch > > > is proposed by a committer, then you need another committer to approve > > it. > > > We need to make sure that a patch has to be reviewed by a committer other > > > than the author. > > > > > > > b.How much time give the committer the chance to say no? > > > > > > > This depends. In general, if a committer thinks it is fine to merge then > > it > > > can merge the patch/PR. But other committers have the rights to revert > > the > > > patch/PR, for example if you are not an expert of this area but he/she > > is, > > > and you even do not ask for his/her comments. So I think > > > during collaboration, you will find the suitable way to decide whether it > > > is OK to merge a PR. We do not need to define everything explicitly. > > > > > > > But since people work at the different timezone, it's better to hold > > the patch for one day at least, so people have a chance to review the > > change and express the different opinion if they want. > > It isn't a good practice to submit and then revert patch frequently, I > > think. > > > > > > Once all questions get the resonable answer, we can make a vote. > > > > If anyone has a new idea(e.g. submodule, dev/pr/release branch, > > > > backport, LTS) send your proprosal to dev list and let community > > > > discuss and vote. > > > > But before the proprosal is accepted by the community, why we stop to > > > > use the current workflow and make our work stuck? > > > > > > > > Thanks > > > > Xiang > > > > > > > > On Wed, D
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
What I mean is that, nobody wants its patch to be reverted right? So you will find a proper way to archive this. There is no straight forward rule on how much time to wait. For me on HBase, this depends on lots of things. If it is only a typo then I will merge it immediately. If it is a simple bug fix, I will wait a bit long and if some committers are familiar with this part, I will try to ask their opinions. And if this is a very big new feature, sometimes people will even send an email to the mailing list to attract more reviews before committing. So in general, I do not think there is an one-for-all rule. NuttX community has its own culture, and the ‘rule’ will be set up though practice. Thanks. Xiang Xiao 于2019年12月25日 周三19:50写道: > On Wed, Dec 25, 2019 at 2:30 PM 张铎(Duo Zhang) > wrote: > > > > Xiang Xiao 于2019年12月25日周三 下午1:36写道: > > > > > Yes, I agree that we shouldn't make the workflow too hard to scare > > > people for contribution. > > > NuttX isn't a new project, it's open source for more than ten years > > > and has a mature workflow, the whole community is already familiar > > > with it. > > > Let me summary the current workflow: > > > 1.User send patch against master to > > > https://groups.google.com/forum/#!forum/nuttx or > > > 2.User send PR against master to > > > https://bitbucket.org/nuttx/nuttx/src/master/ > > > 3.Greg review and merge the change to master(with some modification if > > > needed) > > > 4.Greg make a official release and create a tag to mark the point > > > every two(or three?) months > > > To "be apache way", the required change is only item 3&4: all > > > committer need involve the reviewing and release process. > > > So, I suggest that we adapter the current workflow with as minimal > > > changes as possible: > > > 1.User send patch against master to dev@nuttx.apache.org or > > > 2.User send PR against master to > https://github.com/apache/incubator-nuttx > > > 3.Committer review and merge the change to master(with some > > > modification if needed) > > > 4.Committer make a official release and create a tag to mark the point > > > every two(or three?) months > > > We only need to disscuss how committer review the change and make the > > > release. > > > Since we have two month for the next release, let's focus on the > > > review process in this time. > > > Here are some questions I have, other may add more: > > > a.How many committers need approve the patch before it can merge? > > > > > Usually one committer is enough, the only different is that, if the patch > > is proposed by a committer, then you need another committer to approve > it. > > We need to make sure that a patch has to be reviewed by a committer other > > than the author. > > > > > b.How much time give the committer the chance to say no? > > > > > This depends. In general, if a committer thinks it is fine to merge then > it > > can merge the patch/PR. But other committers have the rights to revert > the > > patch/PR, for example if you are not an expert of this area but he/she > is, > > and you even do not ask for his/her comments. So I think > > during collaboration, you will find the suitable way to decide whether it > > is OK to merge a PR. We do not need to define everything explicitly. > > > > But since people work at the different timezone, it's better to hold > the patch for one day at least, so people have a chance to review the > change and express the different opinion if they want. > It isn't a good practice to submit and then revert patch frequently, I > think. > > > > Once all questions get the resonable answer, we can make a vote. > > > If anyone has a new idea(e.g. submodule, dev/pr/release branch, > > > backport, LTS) send your proprosal to dev list and let community > > > discuss and vote. > > > But before the proprosal is accepted by the community, why we stop to > > > use the current workflow and make our work stuck? > > > > > > Thanks > > > Xiang > > > > > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean < > jus...@classsoftware.com> > > > wrote: > > > > > > > > Hi, > > > > > > > > Some observations that might apply. > > > > > > > > I've used GitFlow on a few projects here at Apache and elsewhere, it > > > does have some downsides, it’s overly complex and confuses beginners > > > (particularly those unfamiliar with git),tends to create long lived > > > branches (which are hard to merge), master and develop (or whatever you > > > call the main two branches) tend to subtly get out of sync over time. > > > > > > > > You can change the GitHub default branch (you need to ask infra). A > > > bigger issue with having master / develop and if you don’t merge > frequently > > > is that people don’t think the committers are that active, external > people > > > don't tend to look at activity on the branches. > > > > > > > > Note that Apache Git/GitHub has some restrictions, we don’t want > history > > > to be rewritten for legal and provenance reasons so a couple of things > you > > > may be
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Wed, Dec 25, 2019 at 2:30 PM 张铎(Duo Zhang) wrote: > > Xiang Xiao 于2019年12月25日周三 下午1:36写道: > > > Yes, I agree that we shouldn't make the workflow too hard to scare > > people for contribution. > > NuttX isn't a new project, it's open source for more than ten years > > and has a mature workflow, the whole community is already familiar > > with it. > > Let me summary the current workflow: > > 1.User send patch against master to > > https://groups.google.com/forum/#!forum/nuttx or > > 2.User send PR against master to > > https://bitbucket.org/nuttx/nuttx/src/master/ > > 3.Greg review and merge the change to master(with some modification if > > needed) > > 4.Greg make a official release and create a tag to mark the point > > every two(or three?) months > > To "be apache way", the required change is only item 3&4: all > > committer need involve the reviewing and release process. > > So, I suggest that we adapter the current workflow with as minimal > > changes as possible: > > 1.User send patch against master to dev@nuttx.apache.org or > > 2.User send PR against master to https://github.com/apache/incubator-nuttx > > 3.Committer review and merge the change to master(with some > > modification if needed) > > 4.Committer make a official release and create a tag to mark the point > > every two(or three?) months > > We only need to disscuss how committer review the change and make the > > release. > > Since we have two month for the next release, let's focus on the > > review process in this time. > > Here are some questions I have, other may add more: > > a.How many committers need approve the patch before it can merge? > > > Usually one committer is enough, the only different is that, if the patch > is proposed by a committer, then you need another committer to approve it. > We need to make sure that a patch has to be reviewed by a committer other > than the author. > > > b.How much time give the committer the chance to say no? > > > This depends. In general, if a committer thinks it is fine to merge then it > can merge the patch/PR. But other committers have the rights to revert the > patch/PR, for example if you are not an expert of this area but he/she is, > and you even do not ask for his/her comments. So I think > during collaboration, you will find the suitable way to decide whether it > is OK to merge a PR. We do not need to define everything explicitly. > But since people work at the different timezone, it's better to hold the patch for one day at least, so people have a chance to review the change and express the different opinion if they want. It isn't a good practice to submit and then revert patch frequently, I think. > > Once all questions get the resonable answer, we can make a vote. > > If anyone has a new idea(e.g. submodule, dev/pr/release branch, > > backport, LTS) send your proprosal to dev list and let community > > discuss and vote. > > But before the proprosal is accepted by the community, why we stop to > > use the current workflow and make our work stuck? > > > > Thanks > > Xiang > > > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean > > wrote: > > > > > > Hi, > > > > > > Some observations that might apply. > > > > > > I've used GitFlow on a few projects here at Apache and elsewhere, it > > does have some downsides, it’s overly complex and confuses beginners > > (particularly those unfamiliar with git),tends to create long lived > > branches (which are hard to merge), master and develop (or whatever you > > call the main two branches) tend to subtly get out of sync over time. > > > > > > You can change the GitHub default branch (you need to ask infra). A > > bigger issue with having master / develop and if you don’t merge frequently > > is that people don’t think the committers are that active, external people > > don't tend to look at activity on the branches. > > > > > > Note that Apache Git/GitHub has some restrictions, we don’t want history > > to be rewritten for legal and provenance reasons so a couple of things you > > may be used to doing outside of Apache may not be possible. Squashing > > commits in some projects tends to be frowned on for this reasons. Similarly > > we need to know the author of any change. > > > > > > Thanks, > > > Justin > > > > > > > >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Hi, > Usually one committer is enough, the only different is that, if the patch > is proposed by a committer, then you need another committer to approve it. > We need to make sure that a patch has to be reviewed by a committer other > than the author. This depends on the projects, some don’t have reviews and the committer can commit straight to master. It’s going to vary project by project. > But other committers have the rights to revert the > patch/PR This is referred to a a veto and all projects allow this that I’m aware of. They are however very rare or non-existent, as changes are usually discussed and agree on before hand. They must have a valid technical reason or they are invalid. >> Once all questions get the resonable answer, we can make a vote. >> If anyone has a new idea(e.g. submodule, dev/pr/release branch, >> backport, LTS) send your proprosal to dev list and let community >> discuss and vote. I would try to reduce the amount of voting for things like this, just discuss and reach consensus rather than voting. Voting can make winners and looser and split communities. Thanks, Justin
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Xiang Xiao 于2019年12月25日周三 下午1:36写道: > Yes, I agree that we shouldn't make the workflow too hard to scare > people for contribution. > NuttX isn't a new project, it's open source for more than ten years > and has a mature workflow, the whole community is already familiar > with it. > Let me summary the current workflow: > 1.User send patch against master to > https://groups.google.com/forum/#!forum/nuttx or > 2.User send PR against master to > https://bitbucket.org/nuttx/nuttx/src/master/ > 3.Greg review and merge the change to master(with some modification if > needed) > 4.Greg make a official release and create a tag to mark the point > every two(or three?) months > To "be apache way", the required change is only item 3&4: all > committer need involve the reviewing and release process. > So, I suggest that we adapter the current workflow with as minimal > changes as possible: > 1.User send patch against master to dev@nuttx.apache.org or > 2.User send PR against master to https://github.com/apache/incubator-nuttx > 3.Committer review and merge the change to master(with some > modification if needed) > 4.Committer make a official release and create a tag to mark the point > every two(or three?) months > We only need to disscuss how committer review the change and make the > release. > Since we have two month for the next release, let's focus on the > review process in this time. > Here are some questions I have, other may add more: > a.How many committers need approve the patch before it can merge? > Usually one committer is enough, the only different is that, if the patch is proposed by a committer, then you need another committer to approve it. We need to make sure that a patch has to be reviewed by a committer other than the author. > b.How much time give the committer the chance to say no? > This depends. In general, if a committer thinks it is fine to merge then it can merge the patch/PR. But other committers have the rights to revert the patch/PR, for example if you are not an expert of this area but he/she is, and you even do not ask for his/her comments. So I think during collaboration, you will find the suitable way to decide whether it is OK to merge a PR. We do not need to define everything explicitly. > Once all questions get the resonable answer, we can make a vote. > If anyone has a new idea(e.g. submodule, dev/pr/release branch, > backport, LTS) send your proprosal to dev list and let community > discuss and vote. > But before the proprosal is accepted by the community, why we stop to > use the current workflow and make our work stuck? > > Thanks > Xiang > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean > wrote: > > > > Hi, > > > > Some observations that might apply. > > > > I've used GitFlow on a few projects here at Apache and elsewhere, it > does have some downsides, it’s overly complex and confuses beginners > (particularly those unfamiliar with git),tends to create long lived > branches (which are hard to merge), master and develop (or whatever you > call the main two branches) tend to subtly get out of sync over time. > > > > You can change the GitHub default branch (you need to ask infra). A > bigger issue with having master / develop and if you don’t merge frequently > is that people don’t think the committers are that active, external people > don't tend to look at activity on the branches. > > > > Note that Apache Git/GitHub has some restrictions, we don’t want history > to be rewritten for legal and provenance reasons so a couple of things you > may be used to doing outside of Apache may not be possible. Squashing > commits in some projects tends to be frowned on for this reasons. Similarly > we need to know the author of any change. > > > > Thanks, > > Justin > > > > >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Yes, I agree that we shouldn't make the workflow too hard to scare people for contribution. NuttX isn't a new project, it's open source for more than ten years and has a mature workflow, the whole community is already familiar with it. Let me summary the current workflow: 1.User send patch against master to https://groups.google.com/forum/#!forum/nuttx or 2.User send PR against master to https://bitbucket.org/nuttx/nuttx/src/master/ 3.Greg review and merge the change to master(with some modification if needed) 4.Greg make a official release and create a tag to mark the point every two(or three?) months To "be apache way", the required change is only item 3&4: all committer need involve the reviewing and release process. So, I suggest that we adapter the current workflow with as minimal changes as possible: 1.User send patch against master to dev@nuttx.apache.org or 2.User send PR against master to https://github.com/apache/incubator-nuttx 3.Committer review and merge the change to master(with some modification if needed) 4.Committer make a official release and create a tag to mark the point every two(or three?) months We only need to disscuss how committer review the change and make the release. Since we have two month for the next release, let's focus on the review process in this time. Here are some questions I have, other may add more: a.How many committers need approve the patch before it can merge? b.How much time give the committer the chance to say no? Once all questions get the resonable answer, we can make a vote. If anyone has a new idea(e.g. submodule, dev/pr/release branch, backport, LTS) send your proprosal to dev list and let community discuss and vote. But before the proprosal is accepted by the community, why we stop to use the current workflow and make our work stuck? Thanks Xiang On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean wrote: > > Hi, > > Some observations that might apply. > > I've used GitFlow on a few projects here at Apache and elsewhere, it does > have some downsides, it’s overly complex and confuses beginners (particularly > those unfamiliar with git),tends to create long lived branches (which are > hard to merge), master and develop (or whatever you call the main two > branches) tend to subtly get out of sync over time. > > You can change the GitHub default branch (you need to ask infra). A bigger > issue with having master / develop and if you don’t merge frequently is that > people don’t think the committers are that active, external people don't tend > to look at activity on the branches. > > Note that Apache Git/GitHub has some restrictions, we don’t want history to > be rewritten for legal and provenance reasons so a couple of things you may > be used to doing outside of Apache may not be possible. Squashing commits in > some projects tends to be frowned on for this reasons. Similarly we need to > know the author of any change. > > Thanks, > Justin > >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Hi, > The style fix should be in one patch not the separated patch. If the > new code has the style problem, contributor should fix it and resend > PR again. While generally if you broke something (like a build) you should be the one to fix it, it’s more encouraging to help out new contributors. In some cases that may mean a committer or PMC member needs to fix a patch to show them what to do in future patches. The users and contributors should be your primary focus. Telling someone to jump through hoops they don’t understand may drive them away, helping them understand what required for future patches/PRs is often better. A poor quality patch can be better than no patch at all, as it may contain a great idea or an important fix, people can collaborate and fine tune it and fix it before it is committed / merged. > Nobody has the right bypass the criticia we will define in the > workflow document and merge the patch(even it just fix the style > issue) directly. Like all guidelines there may be some cases, when this needs to be bypassed e.g urgent security issue or broken build. It certainly should come with a good explanation to why this was needed, but it's better to follow good guideline than have absolute rules. Thanks, Justin
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Hi, Some observations that might apply. I've used GitFlow on a few projects here at Apache and elsewhere, it does have some downsides, it’s overly complex and confuses beginners (particularly those unfamiliar with git),tends to create long lived branches (which are hard to merge), master and develop (or whatever you call the main two branches) tend to subtly get out of sync over time. You can change the GitHub default branch (you need to ask infra). A bigger issue with having master / develop and if you don’t merge frequently is that people don’t think the committers are that active, external people don't tend to look at activity on the branches. Note that Apache Git/GitHub has some restrictions, we don’t want history to be rewritten for legal and provenance reasons so a couple of things you may be used to doing outside of Apache may not be possible. Squashing commits in some projects tends to be frowned on for this reasons. Similarly we need to know the author of any change. Thanks, Justin
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
I think there may be 2 schools of thought on style fixes. Imagine up front creating a commit before changing code in files that fixes ONLY all of the style issues. Essentially this commit should contain only white space changes. If the commit is marked as such. It can be mechanically validated by comparing the binary result of the build Before & After the application Of the style commit. The next commit in the set would have the actual changes to the code. This is where experts in the subject matter can add value reviewing it. Monster PRs ( Lots of files changed with lots of lines of changed) are very difficult to review. If the majority of the changes are style only. The above method Reduces the possibility of error While minimizing the burden on subject matter experts. On Tue, Dec 24, 2019, 6:18 PM Xiang Xiao wrote: > On Wed, Dec 25, 2019 at 6:52 AM Gregory Nutt wrote: > > > > > > > If they are related / dependent on each other, then I think those > > > kinds of patchsets should be encapsulated in one branch. > > > > The need to be applied and committed in sequence. Sometimes the final > > patch is the one that fixes the coding style. This is inherently very > > manual. > > > > The style fix should be in one patch not the separated patch. If the > new code has the style problem, contributor should fix it and resend > PR again. > If the code base has the style issue, we should send new PR to fix the > whole style issue. > > Of course, some committer may want to help fix the issue. It's fine, > but the new change still need pass all check and reviewed by other > committer before merge. > Nobody has the right bypass the criticia we will define in the > workflow document and merge the patch(even it just fix the style > issue) directly. >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
I think you have landed on the very motivation behind, and the very benefit that pull requests offer over patches. The submitter(s) is/are the one(s) who know how the pieces fit together. It is they that are responsible for creating something that's mergeabel. A set or PRs with a "No conflicts" status. Just imagine the streams of patches that come in chunks as individual PR. If after 1 PR comes in it causes a second PR of the groups to become conflicted. The onus is on the submitter to rebase and resolve the issues. On past projects that I have worked on the process was to carry patches and apply them in the build. This gave me a sense of security in that I could see all of the deltas from upstream in the patch set. Then other members of the team suggested that we carry these changes as commits on top of (re based on) upstream. This left me totally uncomfortable because it completely changed the why I was working. But what I learned was the key benefit of this methodology is that: it is far better to find the conflicts during a rebase in a git re base session then it is to try to decipher failed patch applications in a build. After doing it with this re based workflow I realized the benefits. It was super uncomfortable at 1st but now it's 2nd nature and much, much more efficient not to mention foolproof. This is essentially what happens when A PR Has conflicts and the submitter is asked to resolve them. They re base on the current master and they are very quickly able to ensure their changes are now proper in the new context. David On Tue, Dec 24, 2019, 2:52 PM Gregory Nutt wrote: > > > If they are related / dependent on each other, then I think those > > kinds of patchsets should be encapsulated in one branch. > > The need to be applied and committed in sequence. Sometimes the final > patch is the one that fixes the coding style. This is inherently very > manual. > > >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
I do not think it is a big deal to force the base branch for a PR. You are free to choose the way you like, just tell users which branch to use when creating a PR. In ASF, like Hadoop and HBase, maser is the dev branch and by default all PR must be created against the master branch. There are users open a PR against other branches, then we just tell them to open a new PR against master, and close the current one (and for hadoop, the 'master' branch is actually called 'trunk'...). And IIRC, there are other projects in the ASF want user to open PR against the current release branch, and the commiters will cherry-pick the commit back to master branch. Of course sometimes the user will just leave and not open the PR as his/her code base is not against the master branch and he/she do not want to spend much time on porting, that's fine. This is open source, people come and go. In general, just start a vote and let PPMC decided the branching strategy. And do we have a wiki page to record the discussion result? I think we'd better reach agreement step by step, and this is good sign to the IPMC, that we are making progress. For other things, like whether we should squash all the commits in a PR into one when merging, or there are dependencis between PRs, we can discuess them in another thread. Thanks. Brennan Ashton 于2019年12月25日周三 上午8:05写道: > On Tue, Dec 24, 2019, 3:13 PM Gregory Nutt wrote: > > > > > > > > >> If they are related / dependent on each other, then I think those > > >> kinds of patchsets should be encapsulated in one branch. > > > > > > The need to be applied and committed in sequence. Sometimes the final > > > patch is the one that fixes the coding style. This is inherently very > > > manual. > > They need to be merged separately too since the author is often > > different on each patch. > > > > Why does the authors matter. There is no reason a patchset or PR needs to > be squashed into a single commit, they just should not be broken along the > way. > > Also order in a patch set is usually defined by a number prefix for example > this is how it is defined by the Linux kernel, but is inline with most > projects that do mailing list patches. > > > https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#the-canonical-patch-format > > > There is really nothing so unique about this project that we need to get > too creative. > > --Brennan > > > >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Wed, Dec 25, 2019 at 6:52 AM Gregory Nutt wrote: > > > > If they are related / dependent on each other, then I think those > > kinds of patchsets should be encapsulated in one branch. > > The need to be applied and committed in sequence. Sometimes the final > patch is the one that fixes the coding style. This is inherently very > manual. > The style fix should be in one patch not the separated patch. If the new code has the style problem, contributor should fix it and resend PR again. If the code base has the style issue, we should send new PR to fix the whole style issue. Of course, some committer may want to help fix the issue. It's fine, but the new change still need pass all check and reviewed by other committer before merge. Nobody has the right bypass the criticia we will define in the workflow document and merge the patch(even it just fix the style issue) directly.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Tue, Dec 24, 2019, 3:13 PM Gregory Nutt wrote: > > > > >> If they are related / dependent on each other, then I think those > >> kinds of patchsets should be encapsulated in one branch. > > > > The need to be applied and committed in sequence. Sometimes the final > > patch is the one that fixes the coding style. This is inherently very > > manual. > They need to be merged separately too since the author is often > different on each patch. > Why does the authors matter. There is no reason a patchset or PR needs to be squashed into a single commit, they just should not be broken along the way. Also order in a patch set is usually defined by a number prefix for example this is how it is defined by the Linux kernel, but is inline with most projects that do mailing list patches. https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#the-canonical-patch-format There is really nothing so unique about this project that we need to get too creative. --Brennan >
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
If they are related / dependent on each other, then I think those kinds of patchsets should be encapsulated in one branch. The need to be applied and committed in sequence. Sometimes the final patch is the one that fixes the coding style. This is inherently very manual. They need to be merged separately too since the author is often different on each patch.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
If they are related / dependent on each other, then I think those kinds of patchsets should be encapsulated in one branch. The need to be applied and committed in sequence. Sometimes the final patch is the one that fixes the coding style. This is inherently very manual.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Tue, Dec 24, 2019 at 3:44 PM Gregory Nutt wrote: > Many branches would be awkward on patch sets that consist of a dozen or > so individual patches that cannot be squashed together because they have > different authors. We get lots of large patch sets from Xiaomi like > that. To make things more complex, there is an ordering in which the > patches must be apply. A given patch may not apply until a preceding > patch by a different author is first merged. If they are related / dependent on each other, then I think those kinds of patchsets should be encapsulated in one branch. Nathan
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
> > > > > Git's claim to fame is supposed to be the cheapness of branches. What if > each PR becomes its own branch and then it either: (a) gets worked on, (b) > applied to master, or (c) deleted? > As I have already said PRs automatically are branches in GitHub even if they are not shown in the GitHub UI (why would they, they are shown as a PR) https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally --Brennan >
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
It is OK Look at microsoft/vscode 58,891 commits 360 branches 0 packages 145 releases 1,048 contributors MIT The pr-branches are deleted on merge. The relasease branches foreverever WIP branches are there until merged, or superseded. -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Tuesday, December 24, 2019 12:44 PM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) > Git's claim to fame is supposed to be the cheapness of branches. What if > each PR becomes its own branch and then it either: (a) gets worked on, (b) > applied to master, or (c) deleted? I think that would work fine. We need to verify that we can actually change the PR base, but if so that would keep things more independent. Perhaps it could help us with patches where sometimes there are patches that depend on each other or interact with other because they modify the same area of code. Using git to help merge patches would be easier if the patches were on different branches. We would probably need some encoding of branch names to associate them with patches or PRs. Many branches would be awkward on patch sets that consist of a dozen or so individual patches that cannot be squashed together because they have different authors. We get lots of large patch sets from Xiaomi like that. To make things more complex, there is an ordering in which the patches must be apply. A given patch may not apply until a preceding patch by a different author is first merged. The number should not be a big concern. Over time, we will end up with 100's of branches eventually. Each release will probably have to be on a branch. Greg
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Git's claim to fame is supposed to be the cheapness of branches. What if each PR becomes its own branch and then it either: (a) gets worked on, (b) applied to master, or (c) deleted? I think that would work fine. We need to verify that we can actually change the PR base, but if so that would keep things more independent. Perhaps it could help us with patches where sometimes there are patches that depend on each other or interact with other because they modify the same area of code. Using git to help merge patches would be easier if the patches were on different branches. We would probably need some encoding of branch names to associate them with patches or PRs. Many branches would be awkward on patch sets that consist of a dozen or so individual patches that cannot be squashed together because they have different authors. We get lots of large patch sets from Xiaomi like that. To make things more complex, there is an ordering in which the patches must be apply. A given patch may not apply until a preceding patch by a different author is first merged. The number should not be a big concern. Over time, we will end up with 100's of branches eventually. Each release will probably have to be on a branch. Greg
RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
The Aha moment has arrived - You got - What is your github name? -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Tuesday, December 24, 2019 12:28 PM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) On Tue, Dec 24, 2019 at 3:15 PM Gregory Nutt wrote: > > >> Also, is there a way to take a PR against master and apply it as a > >> branch? > > > > I generally do that by taking the PR as a patch, then applying the > > patch on a branch. > > > > But it looks like you can do that with github: > > > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request > > > We will need to experiment with that, but if it works then we could > continue to use the dev branch with no PR problems. If we get a PR on > master, we could just change the base to dev. > > That, of course, depends on keeping dev fairly clean and freshly rebased > to master. If things are going to linger on dev, we should move them to > another branch. Git's claim to fame is supposed to be the cheapness of branches. What if each PR becomes its own branch and then it either: (a) gets worked on, (b) applied to master, or (c) deleted? Nathan
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
I think we should strive to keep master as close to "releasable" as possible at all times, do development on dev branch(es), and create release branches to which changes are only made by backporting from master. I think this is closer to a CI/CD (Continuous Integration / Continuous Delivery) style. I tend to agree with, especially if we have the ability to change the base of PRs against master to dev. To me, that would solve any usability problems with keeping master the master and dev the development branch. I agree with your other points as well. There have been a couple of times where I downloaded applications sources and built them on master assuming that is the correct place... why wouldn't it be? Then finding that they do not work and that you really have to build on some branch. It would be best for every one if we didn't have to make things any more complex for the end-user. Greg
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Tue, Dec 24, 2019 at 3:15 PM Gregory Nutt wrote: > > >> Also, is there a way to take a PR against master and apply it as a > >> branch? > > > > I generally do that by taking the PR as a patch, then applying the > > patch on a branch. > > > > But it looks like you can do that with github: > > > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request > > > We will need to experiment with that, but if it works then we could > continue to use the dev branch with no PR problems. If we get a PR on > master, we could just change the base to dev. > > That, of course, depends on keeping dev fairly clean and freshly rebased > to master. If things are going to linger on dev, we should move them to > another branch. Git's claim to fame is supposed to be the cheapness of branches. What if each PR becomes its own branch and then it either: (a) gets worked on, (b) applied to master, or (c) deleted? Nathan
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Tue, Dec 24, 2019 at 9:47 AM Gregory Nutt wrote: > That would simplify accepting PRs since the uniformed will probably > continue to submit against master. This would make that behavior > workable. Semantically, I would have to wrap my head around the notion > that the master is not the master but a development branch. But even > old dogs can learn new tricks with enough time. On the issue of whether master should be a dev branch or not, my 2 cents: I think we should strive to keep master as close to "releasable" as possible at all times, do development on dev branch(es), and create release branches to which changes are only made by backporting from master. I think this is closer to a CI/CD (Continuous Integration / Continuous Delivery) style. Why we would want that: (1) I think most users will assume that master should be buildable and usable. (2) If master is buildable and usable at all times, it will probably get wider testing and therefore any new problems should be detected quickly. (Case in point: I caught a few issues the same day they were introduced by using master every day.) (3) If master becomes a dumping ground for any changes and then we have to sift through them to decide what to port to a stable branch, it might become a mess. I think it's best to review before it comes into the tree, and then if approved, bring it in decisively. Just food for (collective) thought. Nathan
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Also, is there a way to take a PR against master and apply it as a branch? I generally do that by taking the PR as a patch, then applying the patch on a branch. But it looks like you can do that with github: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request We will need to experiment with that, but if it works then we could continue to use the dev branch with no PR problems. If we get a PR on master, we could just change the base to dev. That, of course, depends on keeping dev fairly clean and freshly rebased to master. If things are going to linger on dev, we should move them to another branch.
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
Also, is there a way to take a PR against master and apply it as a branch? I generally do that by taking the PR as a patch, then applying the patch on a branch. But it looks like you can do that with github: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
On Tue, Dec 24, 2019 at 9:47 AM Gregory Nutt wrote: > > I have some doubts: If an an end-user clones or forks the change, it > would still default to creating only the master branch. You would not > want users working on the master branch, you would want them to be > working in the stable branch. There could potentially bad changes on > the master. I haven't yet studied what David wrote in response, but I just wanted to say: This is why, in the Confluence workflow document, I want to spell out: * How to obtain the code * What steps to take before working on a PR Namely, those steps are: to clone git and then immediately create a branch to work on any changes. (I never code directly on master.) If someone doesn't do that, I think we'd need to point them to that document. Also, is there a way to take a PR against master and apply it as a branch? Nathan
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
An alternative way could be make master/trunk branch a dev branch and allow all PRs to checked in, at the same time, maintain a stable branch which you can cut release (as release manager) and pick up PRs that you carefully reviewed. - This is the Apache way and I guess can achieve the same goal. That would simplify accepting PRs since the uniformed will probably continue to submit against master. This would make that behavior workable. Semantically, I would have to wrap my head around the notion that the master is not the master but a development branch. But even old dogs can learn new tricks with enough time. I can see how this works well into a release strategy. But what about uses who want to work from clones or forks? I have some doubts: If an an end-user clones or forks the change, it would still default to creating only the master branch. You would not want users working on the master branch, you would want them to be working in the stable branch. There could potentially bad changes on the master. Is there a way to force the initial branch to be the stable branch instead of master. If they make changes that they want to submit on the stable branch branch, it seems to me that you have essentially the same communication problem. They would need to transfer their changes to the master branch before creating the PR. Is that right? Another nit and this is just probably due to my fumble fingers: I often get weird things happening when I add changes to branches, then squash them into the stable branch (master in this case). At that point the histories of the two branches have diverged. I can usually reuse the old branch by rebasing and pushing the branch with --force. But the history will still not be 100% the same as the stable branch. If I lose confidence in the content of a development branch (which is fairly often), I usually just delete the branch and recreate it clean. But we cannot do that if master is the stable. We can't delete master can we? There are ways to force to branches to be identical (in both content and history) but I would have to get used to doing that. It seems that this strategy adds some nice simplifications in one area but at least raises some questions in others. Perhaps GIT power users could answer all of those questions (but let's place not clutter up the list by solving the full workflow here. Please contribute your thoughts directly as comments at https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton).
Software release life cycle choices could have implications on workflow (was RE: Single Committer)
>An alternative way could be make master/trunk branch a dev branch and allow >all PRs to checked in, at the same time, maintain a stable branch which you >can cut release (as release manager) and pick up PRs that you carefully >reviewed. - This is the Apache way and I guess can achieve the same goal. +1 I think because stable says what it is. Junping suggestion is an excellent one. I am not endorsing this tool, but it is really slick, even just to get the concepts from the video. (in the vedio replace `master` with `stable` with and `development` with master) https://blog.axosoft.com/gitflow/ Some questions to discuss as we move forward (no need for immediate discussion)? What will our Software release life cycle[1] look like? Do we choose to do LTS[2]? Do we do release branching? Do we do backports [3] on to release candidates[1]? Do we do hot fixes[5]? David [1] https://en.wikipedia.org/wiki/Software_release_life_cycle [2] LTS is an abbreviation for “Long Term Support”. [3] https://en.wikipedia.org/wiki/Backporting [4] https://softwareengineering.stackexchange.com/questions/288935/difference-between-hotfix-and-bugfix -Original Message- From: 俊平堵 [mailto:junping...@apache.org] Sent: Monday, December 23, 2019 6:27 PM To: dev@nuttx.apache.org Subject: Re: Single Committer bq. I would create a dev branch and expect all PRs to be against that dev branch. An alternative way could be make master/trunk branch a dev branch and allow all PRs to checked in, at the same time, maintain a stable branch which you can cut release (as release manager) and pick up PRs that you carefully reviewed. - This is the Apache way and I guess can achieve the same goal. Thanks, Junping Gregory Nutt 于2019年12月24日周二 上午8:51写道: > Recent events have made me reconsider some decisions I made. I threw > off the single committer mantle when I saw the abuse of privilege in the > repositories. If the PPMC agrees to it, I will take up that role again. > > But let's be frank. Here is what I think that means: > > * I would be sole committer of changes. The repositories would have > to be treated as read-only just as back in the Bitbucket days. > * I would grandfather in the i.MXRT changes. > * I will decline all workflow related changes until workflow > requirements are established (that is my only real motivation for > suggesting this: To make certain that we have proper requirements > in place before we accept PX4 workflow into our repositories. We > need to do this right and I am willing to protect the repositories > until the workflow requirements are established. I expect that to > take about two weeks.) > * I would create a dev branch and expect all PRs to be against that > dev branch. > * As soon as the PPMC is confident that it has the processes in place > to handle the commit workload I will gladly relinquish this role. > * THIS IS NOT THE APACHE WAY. This is an interim dictatorship role to > expedite the avalanche of commits expected after the holidays. > > If any of this concerns people, please "Just Say No." I am not married > to the idea and I am not forcefully advocating it. This is what people > wanted me to do a few days ago and if I can protect our right to define > the workflow, then I will do it. For me it is a sacrifice that I would > take with no pleasure in. > > Pros: This will provide project continuity until the PPMC is fully > functional. Having workflow requirements will be a huge step in that > direction. People stressed about the commit process can relax with > confidence. This will protect the code base from premature work flow > changes until we have an understanding of what we want. No harm is done > by deferring workflow changes until we as a team are prepared to deal > with them. > > Cons: This is not the Apache way. People who are trying to bulldoze > the PX4 work flow into the repositories will hate the idea. Mentors > will hate the idea. An approach more consistent with the Apache way > would just be to let the chaos prevail. That is fine with me too as > long as we do not let PX4 advocates take away our group right to define > our own workflow. We can still just put all workflow changes on hold > until we have the requirements in hand. > > I am not pushing anything. Think about it and let me know what you > would like to do. > > Greg > > >