Re: Start of the NuttX 9.0 release cycle
On Thu, Apr 23, 2020 at 8:02 PM Brennan Ashton wrote: > > On Thu, Apr 23, 2020, 4:52 PM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > > Not much to it but yeah. Do you want me to push a RC0 to staging tonight, > > > we just need to tag the apps and os and kick off a build the passes. > > > > The PRs we've been talking about in Github are now merged, can you > > move forward with this? > > > > Happy to do it this evening (few hours from now). > > I would tag what is currently the tip of incubating-nuttx and > incubating-nuttx-apps on the releases/9.0 both as nuttx-9.0.0-RC0 > > Does this sound like a good plan? Thank you to Abdelatif and Brennan for pushing this forward! Nathan
Re: Start of the NuttX 9.0 release cycle
Awesome! Thanks! Meanwhile, I'm doing some tests with the branch locally. All seem normal. On Fri, Apr 24, 2020 at 1:02 AM Brennan Ashton wrote: > > On Thu, Apr 23, 2020, 4:52 PM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > > Not much to it but yeah. Do you want me to push a RC0 to staging tonight, > > > we just need to tag the apps and os and kick off a build the passes. > > > > The PRs we've been talking about in Github are now merged, can you > > move forward with this? > > > > Happy to do it this evening (few hours from now). > > I would tag what is currently the tip of incubating-nuttx and > incubating-nuttx-apps on the releases/9.0 both as nuttx-9.0.0-RC0 > > Does this sound like a good plan? > > --Brennan > > >
Re: Start of the NuttX 9.0 release cycle
On Thu, Apr 23, 2020, 4:52 PM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > Not much to it but yeah. Do you want me to push a RC0 to staging tonight, > > we just need to tag the apps and os and kick off a build the passes. > > The PRs we've been talking about in Github are now merged, can you > move forward with this? > Happy to do it this evening (few hours from now). I would tag what is currently the tip of incubating-nuttx and incubating-nuttx-apps on the releases/9.0 both as nuttx-9.0.0-RC0 Does this sound like a good plan? --Brennan >
Re: Start of the NuttX 9.0 release cycle
> Not much to it but yeah. Do you want me to push a RC0 to staging tonight, > we just need to tag the apps and os and kick off a build the passes. The PRs we've been talking about in Github are now merged, can you move forward with this? On Thu, Apr 23, 2020 at 2:23 AM Brennan Ashton wrote: > > On Wed, Apr 22, 2020, 6:11 PM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > > Correct. I’ve created them for you. > > > > Thanks, Justin. > > Brennan, is your script wired to those locations? > > > > Not much to it but yeah. Do you want me to push a RC0 to staging tonight, > we just need to tag the apps and os and kick off a build the passes. > > Let me send a PR that will cause the CI to perform a build on tag. It's the > non controversial part of the packaging PR. This way we know the two tags > pass all the tests. > > > > There is a new PR that fixes a recent bug [1], that bug exists also in > > the release branch, it looks like a candidate for backporting. > > I'll create a PR for that, if you all agree, please merge. > > > > 1. https://github.com/apache/incubator-nuttx/pull/843 > > > Looks like something we should pull in. I think there might be something > that needs to be backported related to Apps. The build is failing. > > --Brennan
Re: Start of the NuttX 9.0 release cycle
On Wed, Apr 22, 2020, 6:11 PM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > Correct. I’ve created them for you. > > Thanks, Justin. > Brennan, is your script wired to those locations? > Not much to it but yeah. Do you want me to push a RC0 to staging tonight, we just need to tag the apps and os and kick off a build the passes. Let me send a PR that will cause the CI to perform a build on tag. It's the non controversial part of the packaging PR. This way we know the two tags pass all the tests. > There is a new PR that fixes a recent bug [1], that bug exists also in > the release branch, it looks like a candidate for backporting. > I'll create a PR for that, if you all agree, please merge. > > 1. https://github.com/apache/incubator-nuttx/pull/843 Looks like something we should pull in. I think there might be something that needs to be backported related to Apps. The build is failing. --Brennan
Re: Start of the NuttX 9.0 release cycle
> Correct. I’ve created them for you. Thanks, Justin. Brennan, is your script wired to those locations? There is a new PR that fixes a recent bug [1], that bug exists also in the release branch, it looks like a candidate for backporting. I'll create a PR for that, if you all agree, please merge. 1. https://github.com/apache/incubator-nuttx/pull/843 On Wed, Apr 22, 2020 at 11:47 PM Justin Mclean wrote: > > Hi, > > > The tarballs should be uploaded to [1] and/or [2] right? > > Correct. I’ve created them for you. > > Thanks, > Justin
Re: Start of the NuttX 9.0 release cycle
Hi, > The tarballs should be uploaded to [1] and/or [2] right? Correct. I’ve created them for you. Thanks, Justin
Re: Start of the NuttX 9.0 release cycle
The tarballs should be uploaded to [1] and/or [2] right? But I don't see any entry for nuttx/. Should a mentor create it? 1. https://dist.apache.org/repos/dist/dev/incubator/ 2. https://dist.apache.org/repos/dist/release/incubator/ On Tue, Apr 21, 2020 at 5:19 AM Xiang Xiao wrote: > > Yes, we are learning how to make the first apache release. Let's get > it out and refine the process in the next time. Thanks you making this > happen! > > On Tue, Apr 21, 2020 at 6:12 AM Abdelatif Guettouche > wrote: > > > > > Yes, only if the release don't have any bug, but the software always > > > has bug, right? how people fix the issue? the first step is git clone > > > the code from github: > > > 1.Review the difference between the release and master > > > 2.Review the history to see whether other people already fix the issue > > > 3 > > > > I still fail to see how it will make life any harder to find out if a > > bug was fixed on master or not. > > When a release contains a bug, that bug is either fixed on master or > > still not discovered. > > If it was fixed and we think it's crucial enough to re-release with an > > increment patch (say 9.0.1), the user will need to upgrade. > > Otherwise, the user can backport the change himself. > > If the user discovers the bug and fixes it, he can provide a patch and > > we decide to whether we release again or keep it for the next one. > > > > I guess during the branch freezing time, cherry picking is inevitable, > > maybe it was for this one but for releases where showstoppers were > > discovered, we can only cherry-pick them. > > If what you are saying is to keep the commits backported to a minimum, > > then yes, I agree. > > Maybe next time before backporting we call a vote as you suggested and > > not directly create a PR. > > > > Thanks everyone! > > > > It is important for us to learn from this first Apache release and > > perfect the process to make it as smooth as possible each time. > > > > > > On Mon, Apr 20, 2020 at 8:27 PM Alan Carvalho de Assis > > wrote: > > > > > > Yes, he did a great work, this morning for instance he stay up to > > > 5:30AM working on it. > > > > > > So, lets move on with the NuttX 9.0 release and learn from this > > > experience. > > > > > > BR, > > > > > > Alan > > > > > > On 4/20/20, Gregory Nutt wrote: > > > > > > > >> For future 2-month releases, I think that on the branch date, we > > > >> should branch and immediately make -rc1 tarballs. > > > >> > > > >> Then the community can test, report bugs/showstoppers, and those will > > > >> be fixed on master and backported to the branch. > > > >> > > > >> When it seems there are no more showstoppers, make -rc2 tarballs, let > > > >> test a few more days. If no showstoppers this time, re-brand it as the > > > >> final release. > > > > > > > > That sounds perfect. This release was our first experiment. I think we > > > > should get it out the door and start thinking about how we can improve > > > > the release process for the June release. > > > > > > > > I think we owe Abdelatif thanks. What has happened could not have > > > > happened without his contribution. There was no one else standing up to > > > > do this job and Abdelatif stepped in and did it. Their should be no > > > > criticisms because none of us are in a place where we can "cast the > > > > first stones" because we did not do the work. Rather, we should offer > > > > our thanks. Suggestions for improvement are welcome and if you want to > > > > be helpful, they should be included in a release procedure document. > > > > > > > > Thanks, Abde! > > > > > > > > > > > >
Re: Start of the NuttX 9.0 release cycle
Yes, we are learning how to make the first apache release. Let's get it out and refine the process in the next time. Thanks you making this happen! On Tue, Apr 21, 2020 at 6:12 AM Abdelatif Guettouche wrote: > > > Yes, only if the release don't have any bug, but the software always > > has bug, right? how people fix the issue? the first step is git clone > > the code from github: > > 1.Review the difference between the release and master > > 2.Review the history to see whether other people already fix the issue > > 3 > > I still fail to see how it will make life any harder to find out if a > bug was fixed on master or not. > When a release contains a bug, that bug is either fixed on master or > still not discovered. > If it was fixed and we think it's crucial enough to re-release with an > increment patch (say 9.0.1), the user will need to upgrade. > Otherwise, the user can backport the change himself. > If the user discovers the bug and fixes it, he can provide a patch and > we decide to whether we release again or keep it for the next one. > > I guess during the branch freezing time, cherry picking is inevitable, > maybe it was for this one but for releases where showstoppers were > discovered, we can only cherry-pick them. > If what you are saying is to keep the commits backported to a minimum, > then yes, I agree. > Maybe next time before backporting we call a vote as you suggested and > not directly create a PR. > > Thanks everyone! > > It is important for us to learn from this first Apache release and > perfect the process to make it as smooth as possible each time. > > > On Mon, Apr 20, 2020 at 8:27 PM Alan Carvalho de Assis > wrote: > > > > Yes, he did a great work, this morning for instance he stay up to > > 5:30AM working on it. > > > > So, lets move on with the NuttX 9.0 release and learn from this experience. > > > > BR, > > > > Alan > > > > On 4/20/20, Gregory Nutt wrote: > > > > > >> For future 2-month releases, I think that on the branch date, we > > >> should branch and immediately make -rc1 tarballs. > > >> > > >> Then the community can test, report bugs/showstoppers, and those will > > >> be fixed on master and backported to the branch. > > >> > > >> When it seems there are no more showstoppers, make -rc2 tarballs, let > > >> test a few more days. If no showstoppers this time, re-brand it as the > > >> final release. > > > > > > That sounds perfect. This release was our first experiment. I think we > > > should get it out the door and start thinking about how we can improve > > > the release process for the June release. > > > > > > I think we owe Abdelatif thanks. What has happened could not have > > > happened without his contribution. There was no one else standing up to > > > do this job and Abdelatif stepped in and did it. Their should be no > > > criticisms because none of us are in a place where we can "cast the > > > first stones" because we did not do the work. Rather, we should offer > > > our thanks. Suggestions for improvement are welcome and if you want to > > > be helpful, they should be included in a release procedure document. > > > > > > Thanks, Abde! > > > > > > > > >
Re: Start of the NuttX 9.0 release cycle
> Yes, only if the release don't have any bug, but the software always > has bug, right? how people fix the issue? the first step is git clone > the code from github: > 1.Review the difference between the release and master > 2.Review the history to see whether other people already fix the issue > 3 I still fail to see how it will make life any harder to find out if a bug was fixed on master or not. When a release contains a bug, that bug is either fixed on master or still not discovered. If it was fixed and we think it's crucial enough to re-release with an increment patch (say 9.0.1), the user will need to upgrade. Otherwise, the user can backport the change himself. If the user discovers the bug and fixes it, he can provide a patch and we decide to whether we release again or keep it for the next one. I guess during the branch freezing time, cherry picking is inevitable, maybe it was for this one but for releases where showstoppers were discovered, we can only cherry-pick them. If what you are saying is to keep the commits backported to a minimum, then yes, I agree. Maybe next time before backporting we call a vote as you suggested and not directly create a PR. Thanks everyone! It is important for us to learn from this first Apache release and perfect the process to make it as smooth as possible each time. On Mon, Apr 20, 2020 at 8:27 PM Alan Carvalho de Assis wrote: > > Yes, he did a great work, this morning for instance he stay up to > 5:30AM working on it. > > So, lets move on with the NuttX 9.0 release and learn from this experience. > > BR, > > Alan > > On 4/20/20, Gregory Nutt wrote: > > > >> For future 2-month releases, I think that on the branch date, we > >> should branch and immediately make -rc1 tarballs. > >> > >> Then the community can test, report bugs/showstoppers, and those will > >> be fixed on master and backported to the branch. > >> > >> When it seems there are no more showstoppers, make -rc2 tarballs, let > >> test a few more days. If no showstoppers this time, re-brand it as the > >> final release. > > > > That sounds perfect. This release was our first experiment. I think we > > should get it out the door and start thinking about how we can improve > > the release process for the June release. > > > > I think we owe Abdelatif thanks. What has happened could not have > > happened without his contribution. There was no one else standing up to > > do this job and Abdelatif stepped in and did it. Their should be no > > criticisms because none of us are in a place where we can "cast the > > first stones" because we did not do the work. Rather, we should offer > > our thanks. Suggestions for improvement are welcome and if you want to > > be helpful, they should be included in a release procedure document. > > > > Thanks, Abde! > > > > > >
Re: Start of the NuttX 9.0 release cycle
Yes, he did a great work, this morning for instance he stay up to 5:30AM working on it. So, lets move on with the NuttX 9.0 release and learn from this experience. BR, Alan On 4/20/20, Gregory Nutt wrote: > >> For future 2-month releases, I think that on the branch date, we >> should branch and immediately make -rc1 tarballs. >> >> Then the community can test, report bugs/showstoppers, and those will >> be fixed on master and backported to the branch. >> >> When it seems there are no more showstoppers, make -rc2 tarballs, let >> test a few more days. If no showstoppers this time, re-brand it as the >> final release. > > That sounds perfect. This release was our first experiment. I think we > should get it out the door and start thinking about how we can improve > the release process for the June release. > > I think we owe Abdelatif thanks. What has happened could not have > happened without his contribution. There was no one else standing up to > do this job and Abdelatif stepped in and did it. Their should be no > criticisms because none of us are in a place where we can "cast the > first stones" because we did not do the work. Rather, we should offer > our thanks. Suggestions for improvement are welcome and if you want to > be helpful, they should be included in a release procedure document. > > Thanks, Abde! > > >
Re: Start of the NuttX 9.0 release cycle
On Mon, Apr 20, 2020 at 10:55 AM Gregory Nutt wrote: > I think we owe Abdelatif thanks. What has happened could not have > happened without his contribution. > Thank you Abdelatif! :) -adam -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
On Mon, Apr 20, 2020 at 1:55 PM Gregory Nutt wrote: > > > For future 2-month releases, I think that on the branch date, we > > should branch and immediately make -rc1 tarballs. > > > > Then the community can test, report bugs/showstoppers, and those will > > be fixed on master and backported to the branch. > > > > When it seems there are no more showstoppers, make -rc2 tarballs, let > > test a few more days. If no showstoppers this time, re-brand it as the > > final release. > > That sounds perfect. This release was our first experiment. I think we > should get it out the door and start thinking about how we can improve > the release process for the June release. > > I think we owe Abdelatif thanks. What has happened could not have > happened without his contribution. There was no one else standing up to > do this job and Abdelatif stepped in and did it. Their should be no > criticisms because none of us are in a place where we can "cast the > first stones" because we did not do the work. Rather, we should offer > our thanks. Suggestions for improvement are welcome and if you want to > be helpful, they should be included in a release procedure document. I agree! A very BIG thanks to Abdelatif!! Cheers, Nathan
Re: Start of the NuttX 9.0 release cycle
For future 2-month releases, I think that on the branch date, we should branch and immediately make -rc1 tarballs. Then the community can test, report bugs/showstoppers, and those will be fixed on master and backported to the branch. When it seems there are no more showstoppers, make -rc2 tarballs, let test a few more days. If no showstoppers this time, re-brand it as the final release. That sounds perfect. This release was our first experiment. I think we should get it out the door and start thinking about how we can improve the release process for the June release. I think we owe Abdelatif thanks. What has happened could not have happened without his contribution. There was no one else standing up to do this job and Abdelatif stepped in and did it. Their should be no criticisms because none of us are in a place where we can "cast the first stones" because we did not do the work. Rather, we should offer our thanks. Suggestions for improvement are welcome and if you want to be helpful, they should be included in a release procedure document. Thanks, Abde!
Re: Start of the NuttX 9.0 release cycle
On Mon, Apr 20, 2020 at 1:05 PM Gregory Nutt wrote: > >> I agree that we should not let trivial cosmetic things onto the release > >> branch. We should only permit showstopping, critical bugfixes onto the > >> release branch. It is probably a fair comment that we brought too much > >> unimportant stuff in and the confuses things. Let's add that to the > >> TIL: Only showstopping, critical bugfixes my come into the release > >> branch. Once the release branch is cut, it is not changed for any > >> reason other than to correct user-exposure to bugs. > > I don't know how unimportant are the things that got back-ported. > > There are 10 commits back-ported in nuttx/. 3 of them deal with bugs > > in macOS build. 3 are pure typos, 1 is a typo that broke the cxd56xx > > build if certain files were chosen, 1 updated the TODO file (some > > lines about a bug were outdated/incorrect), and last 2 were for tools > > and release notes (both needed by the final release). > > > I don't know how important the macOS changes are, but most if not all of > the others were certainly not show-stopping, critical bugs. The > stability and clarity of the release would probably be more important. For future 2-month releases, I think that on the branch date, we should branch and immediately make -rc1 tarballs. Then the community can test, report bugs/showstoppers, and those will be fixed on master and backported to the branch. When it seems there are no more showstoppers, make -rc2 tarballs, let test a few more days. If no showstoppers this time, re-brand it as the final release. Nathan
Re: Start of the NuttX 9.0 release cycle
I agree that we should not let trivial cosmetic things onto the release branch. We should only permit showstopping, critical bugfixes onto the release branch. It is probably a fair comment that we brought too much unimportant stuff in and the confuses things. Let's add that to the TIL: Only showstopping, critical bugfixes my come into the release branch. Once the release branch is cut, it is not changed for any reason other than to correct user-exposure to bugs. I don't know how unimportant are the things that got back-ported. There are 10 commits back-ported in nuttx/. 3 of them deal with bugs in macOS build. 3 are pure typos, 1 is a typo that broke the cxd56xx build if certain files were chosen, 1 updated the TODO file (some lines about a bug were outdated/incorrect), and last 2 were for tools and release notes (both needed by the final release). I don't know how important the macOS changes are, but most if not all of the others were certainly not show-stopping, critical bugs. The stability and clarity of the release would probably be more important.
Re: Start of the NuttX 9.0 release cycle
On Mon, Apr 20, 2020 at 11:21 PM Abdelatif Guettouche wrote: > > > But this process make the end user hard to know what's in the release > > since so many patches enter into the branch after it create. > > > The difference between commit id or order make the user life even more > > harder. > > I don't see how so. If someone is interested in a released branch why > bother with the diff in history with master? Yes, only if the release don't have any bug, but the software always has bug, right? how people fix the issue? the first step is git clone the code from github: 1.Review the difference between the release and master 2.Review the history to see whether other people already fix the issue 3 > Release notes are there to highlight significant new features and the > branch git log is also available. Release notes also need add a section to describe the pathes we cherry-pick from master after the branch is created since they are very important information. > And users of tarballs don't have any git log. > > > The ideal process is that only the block issue after community vote > > can be cherry-pick to the release branch once the release branch is > > created. > > All of the cherry-picked changes went through PRs, even the most > trivial of them. The reason being (other than to kick the CI checks > and benefit from the tests) is for everyone to see what's being back > ported. > > > On Mon, Apr 20, 2020 at 4:04 PM Gregory Nutt wrote: > > > > > > > The difference between commit id or order make the user life even more > > > harder. > > > > The release tarballs have no GIT information in them. That information > > is available on the branch, but AFAIK all users of releases use the > > tarballs with no git information. Only the release notes describes what > > is in the release. > > > >
Re: Start of the NuttX 9.0 release cycle
> I agree that we should not let trivial cosmetic things onto the release > branch. We should only permit showstopping, critical bugfixes onto the > release branch. It is probably a fair comment that we brought too much > unimportant stuff in and the confuses things. Let's add that to the > TIL: Only showstopping, critical bugfixes my come into the release > branch. Once the release branch is cut, it is not changed for any > reason other than to correct user-exposure to bugs. I don't know how unimportant are the things that got back-ported. There are 10 commits back-ported in nuttx/. 3 of them deal with bugs in macOS build. 3 are pure typos, 1 is a typo that broke the cxd56xx build if certain files were chosen, 1 updated the TODO file (some lines about a bug were outdated/incorrect), and last 2 were for tools and release notes (both needed by the final release). On Mon, Apr 20, 2020 at 4:20 PM Gregory Nutt wrote: > > > > But how we describe 9.0 release? Most people will ask two questiones: > > 1.When(or commit id) the release branch out from master > We know this from the branch creation > > 2.Which patch we cherry-pick from master after the branch is created > This we can get from the pose branch PRs > > and then the huge cherry-pick list just confuse the people why so many > > minor change enter into the release branch. > > I agree that we should not let trivial cosmetic things onto the release > branch. We should only permit showstopping, critical bugfixes onto the > release branch. It is probably a fair comment that we brought too much > unimportant stuff in and the confuses things. Let's add that to the > TIL: Only showstopping, critical bugfixes my come into the release > branch. Once the release branch is cut, it is not changed for any > reason other than to correct user-exposure to bugs. >
Re: Start of the NuttX 9.0 release cycle
> But this process make the end user hard to know what's in the release > since so many patches enter into the branch after it create. > The difference between commit id or order make the user life even more harder. I don't see how so. If someone is interested in a released branch why bother with the diff in history with master? Release notes are there to highlight significant new features and the branch git log is also available. And users of tarballs don't have any git log. > The ideal process is that only the block issue after community vote > can be cherry-pick to the release branch once the release branch is > created. All of the cherry-picked changes went through PRs, even the most trivial of them. The reason being (other than to kick the CI checks and benefit from the tests) is for everyone to see what's being back ported. On Mon, Apr 20, 2020 at 4:04 PM Gregory Nutt wrote: > > > > The difference between commit id or order make the user life even more > > harder. > > The release tarballs have no GIT information in them. That information > is available on the branch, but AFAIK all users of releases use the > tarballs with no git information. Only the release notes describes what > is in the release. > >
Re: Start of the NuttX 9.0 release cycle
But how we describe 9.0 release? Most people will ask two questiones: 1.When(or commit id) the release branch out from master We know this from the branch creation 2.Which patch we cherry-pick from master after the branch is created This we can get from the pose branch PRs and then the huge cherry-pick list just confuse the people why so many minor change enter into the release branch. I agree that we should not let trivial cosmetic things onto the release branch. We should only permit showstopping, critical bugfixes onto the release branch. It is probably a fair comment that we brought too much unimportant stuff in and the confuses things. Let's add that to the TIL: Only showstopping, critical bugfixes my come into the release branch. Once the release branch is cut, it is not changed for any reason other than to correct user-exposure to bugs.
Re: Start of the NuttX 9.0 release cycle
I wouldn't hold up the release because of such issues. First, it is getting better consideration than when I did the job all by myself. It is already and improvemtn. And second, as you say, it is a learning experience. Let's get the job done for better or worse, create a TIL and get ready for the next release. TIL= Things I learned This is release 134. There were 133 released before this and there will be hundreds later. I think we should focus on the process, and less on this particular release. There is nothing to be concerned about this release (at least no more than any previous release) but of course we can do better in the future. Missing the release date causes more harm than any good that can come from delaying the release.
Re: Start of the NuttX 9.0 release cycle
On Mon, Apr 20, 2020 at 10:34 PM Gregory Nutt wrote: > > > > Before we vote, how about we rebase the release/9.0 to the latest > > master? There still have many difference between master and > > release/9.0: > > If we rebase, we would have to update the release notes and related > documentation again. You have to freeze the code somewhere; there will > always be things that are omitted from the release that will have to > wait until the next release. I would vote that we not rebase the > release branch. I think we should keep it as stable as possible and > only bring in bug fixes. > But how we describe 9.0 release? Most people will ask two questiones: 1.When(or commit id) the release branch out from master 2.Which patch we cherry-pick from master after the branch is created and then the huge cherry-pick list just confuse the people why so many minor change enter into the release branch. > The main concern that I have is that there has been no testing or > qualification of the release. It was frozen but never verified > Yes, only test can ensure quality, the branch point isn't so critical. > Greg > >
Re: Start of the NuttX 9.0 release cycle
The difference between commit id or order make the user life even more harder. The release tarballs have no GIT information in them. That information is available on the branch, but AFAIK all users of releases use the tarballs with no git information. Only the release notes describes what is in the release.
Re: Start of the NuttX 9.0 release cycle
On Mon, Apr 20, 2020 at 10:47 PM Abdelatif Guettouche wrote: > > > Abdelatif cherry-pick many patches but not all of them from master > > after we create the release branch which make the end user hard to > > know what in the release and what not. > > That actually was on purpose, I only cherry picked trivial changes or But this process make the end user hard to know what's in the release since so many patches enter into the branch after it create. > bug fixes. The somewhat large changes are left to the next release. > The idea is to not bring large functional changes until they are > stable enough. > > Note that, because the patches were cherry picked, some changes appear > in both master and in the release branch. > ( > $ git log --oneline upstream/master..upstream/releases/9.0 > cb16dfbc30 Update release notes in preparation for the 9.0.0 release. > > > $ git log --oneline upstream/releases/9.0..upstream/master > > d53566118e Update release notes in preparation for the 9.0.0 release. > ... > ) The difference between commit id or order make the user life even more harder. > > > The main concern that I have is that there has been no testing or > > qualification of the release. It was frozen but never verified > > There have been some tests with the backported PRs. A full test will > need the nightly build to intervene. > The ideal process is that only the block issue after community vote can be cherry-pick to the release branch once the release branch is created. > > On Mon, Apr 20, 2020 at 3:22 PM Xiang Xiao wrote: > > > > Before we vote, how about we rebase the release/9.0 to the latest > > master? There still have many difference between master and > > release/9.0: > > git log --oneline apache/master > master.log > > git log --oneline apache/release/9.0 > release.log > > diff master.log release.log > > 1,67c1,10 > > < f706f5e0e8 boards/imxrt1060-evk: Generate nuttx.map in the root directory > > < 2810220ea9 Update defconfig per refresh.sh report > > < 090a4d1690 Update .gitignore per testbuild.sh report > > < 816f624819 tools/Makefile.host: Initialize Q by inspecting V > > < 95e5506637 tools/testbuild.sh: Verify nuttx/apps folder clean after build > > < 48e6b97ca7 tools/testbuild.sh: Check defconfig in the canonical format > > < c153c31fbd tools/refresh.sh: Save defconfig and exit with 1 only > > when the difference exist > > < 5c1497aeb1 tools: Remove the temp variable in checking program exit code > > < cf674ed51c checkpatch.sh: Simplify the code logic, no functional change > > < d53566118e Update release notes in preparation for the 9.0.0 release. > > < af31fd45ae build.yaml: Change arm-11 to arm-12 > > < a59ae5536c github: Add PR Template > > < f2d4e1e2b7 Follow up change in apps "nshlib: Rename sh to source" > > < 3d10f8cf8f Fix nxstyle warning > > < 2a7029dd52 arch/sim: All cpu core need conform to > > CONFIG_SIM_WALLTIME behaviour > > < 87dbd7d52d TODO: Remove simulator SMP bug > > < 2c58b11e50 tools/: Update version generation tools to account for > > the patch number. > > < 2ec8f60e53 Run refresh.sh --silent all > > < 3c4be8710c Fix typo in boards/arm/cxd56xx/drivers/camera/Make.defs > > < 6ad91aeb05 Kconfig: change the stack size default to > > DEFAULT_TASK_STACKSIZE > > < 4b37d0b200 build.yml: Remove the tail space > > < 00049aa482 Fix saved %esp value in up_saveusercontext() for qemu-i486 > > < 0e9b0d7603 sim: Don't generate romfs image if CONFIG_NSH_CUSTOMROMFS=y > > < 15d328c3ab sim: Fix config check for romfs image generation > > < 1d394535cb arch/README.txt: Various improvements to the text > > < 6acaf2afaa Add retry to pull docker image > > < b5a2c7a304 Fix nxstyle warning > > < 89ff9eb046 tools/cfgdefine.c: Remove some string config variable > > from the dequote list > > < e899bc92d2 boards: cxd56: nxstyle fixes for the common code > > < efbd6ada21 boards: cxd56: spresense: nxstyle fixes > > < f2a6d88c9d boards: cxd56: drivers: sensors: nxstyle fix > > < b4cab7eb9e boards: cxd56: drivers: camera: nxstyle fix > > < 43989ee36f sim/nsh2: fix nxserver stack overflow > > < 3776bf6850 sim/configs: update the defconfig > > < 3dd094520c sim/nsh2: remove the specific Make.defs > > < c758cb8341 sim/romfs: add etctmp into ignore list > > < 28e55ab0b1 doc: sem_timedwait: No need to include time.h > > < 781bf68b5c doc: Fix semaphore related function names > > < e855a1b25c doc: Update a few wiki references > > < 674ca92485 spresnese/audio_sdk: Add CONFIG_AUDIO to have a warning free > > build. > > < 366c446003 sim: Provide MODULESTRIP for macOS > > < c61d959655 sim: macOS's strip doesn't have --strip-unneeded option > > < e67062fd88 Config.mk: Provide the default MODULESTRIP > > < 120de788d4 kinetis: Fix typos > > < 9b9d1fc7ca arch/stm32h7: Extend support to all STM32H7x3xx > > < 0668a1552d sim/nsh: dynamic rcS/rcRAW generation support > > < c0c24d29df boards/Board.mk: use genromfs to make romfs image > > < 7396c2d47a boards: arm: cxd56: drivers: audio: nxstyle fixes > > <
Re: Start of the NuttX 9.0 release cycle
> Abdelatif cherry-pick many patches but not all of them from master > after we create the release branch which make the end user hard to > know what in the release and what not. That actually was on purpose, I only cherry picked trivial changes or bug fixes. The somewhat large changes are left to the next release. The idea is to not bring large functional changes until they are stable enough. Note that, because the patches were cherry picked, some changes appear in both master and in the release branch. ( $ git log --oneline upstream/master..upstream/releases/9.0 cb16dfbc30 Update release notes in preparation for the 9.0.0 release. $ git log --oneline upstream/releases/9.0..upstream/master d53566118e Update release notes in preparation for the 9.0.0 release. ... ) > The main concern that I have is that there has been no testing or > qualification of the release. It was frozen but never verified There have been some tests with the backported PRs. A full test will need the nightly build to intervene. On Mon, Apr 20, 2020 at 3:22 PM Xiang Xiao wrote: > > Before we vote, how about we rebase the release/9.0 to the latest > master? There still have many difference between master and > release/9.0: > git log --oneline apache/master > master.log > git log --oneline apache/release/9.0 > release.log > diff master.log release.log > 1,67c1,10 > < f706f5e0e8 boards/imxrt1060-evk: Generate nuttx.map in the root directory > < 2810220ea9 Update defconfig per refresh.sh report > < 090a4d1690 Update .gitignore per testbuild.sh report > < 816f624819 tools/Makefile.host: Initialize Q by inspecting V > < 95e5506637 tools/testbuild.sh: Verify nuttx/apps folder clean after build > < 48e6b97ca7 tools/testbuild.sh: Check defconfig in the canonical format > < c153c31fbd tools/refresh.sh: Save defconfig and exit with 1 only > when the difference exist > < 5c1497aeb1 tools: Remove the temp variable in checking program exit code > < cf674ed51c checkpatch.sh: Simplify the code logic, no functional change > < d53566118e Update release notes in preparation for the 9.0.0 release. > < af31fd45ae build.yaml: Change arm-11 to arm-12 > < a59ae5536c github: Add PR Template > < f2d4e1e2b7 Follow up change in apps "nshlib: Rename sh to source" > < 3d10f8cf8f Fix nxstyle warning > < 2a7029dd52 arch/sim: All cpu core need conform to > CONFIG_SIM_WALLTIME behaviour > < 87dbd7d52d TODO: Remove simulator SMP bug > < 2c58b11e50 tools/: Update version generation tools to account for > the patch number. > < 2ec8f60e53 Run refresh.sh --silent all > < 3c4be8710c Fix typo in boards/arm/cxd56xx/drivers/camera/Make.defs > < 6ad91aeb05 Kconfig: change the stack size default to DEFAULT_TASK_STACKSIZE > < 4b37d0b200 build.yml: Remove the tail space > < 00049aa482 Fix saved %esp value in up_saveusercontext() for qemu-i486 > < 0e9b0d7603 sim: Don't generate romfs image if CONFIG_NSH_CUSTOMROMFS=y > < 15d328c3ab sim: Fix config check for romfs image generation > < 1d394535cb arch/README.txt: Various improvements to the text > < 6acaf2afaa Add retry to pull docker image > < b5a2c7a304 Fix nxstyle warning > < 89ff9eb046 tools/cfgdefine.c: Remove some string config variable > from the dequote list > < e899bc92d2 boards: cxd56: nxstyle fixes for the common code > < efbd6ada21 boards: cxd56: spresense: nxstyle fixes > < f2a6d88c9d boards: cxd56: drivers: sensors: nxstyle fix > < b4cab7eb9e boards: cxd56: drivers: camera: nxstyle fix > < 43989ee36f sim/nsh2: fix nxserver stack overflow > < 3776bf6850 sim/configs: update the defconfig > < 3dd094520c sim/nsh2: remove the specific Make.defs > < c758cb8341 sim/romfs: add etctmp into ignore list > < 28e55ab0b1 doc: sem_timedwait: No need to include time.h > < 781bf68b5c doc: Fix semaphore related function names > < e855a1b25c doc: Update a few wiki references > < 674ca92485 spresnese/audio_sdk: Add CONFIG_AUDIO to have a warning free > build. > < 366c446003 sim: Provide MODULESTRIP for macOS > < c61d959655 sim: macOS's strip doesn't have --strip-unneeded option > < e67062fd88 Config.mk: Provide the default MODULESTRIP > < 120de788d4 kinetis: Fix typos > < 9b9d1fc7ca arch/stm32h7: Extend support to all STM32H7x3xx > < 0668a1552d sim/nsh: dynamic rcS/rcRAW generation support > < c0c24d29df boards/Board.mk: use genromfs to make romfs image > < 7396c2d47a boards: arm: cxd56: drivers: audio: nxstyle fixes > < 5fb835b1df boards: cxd56: enable Nuttx audio driver > < 57e8f0451a cxd56: add initial Nuttx audio driver > < 50431e6694 boards: cxd56: spresense: add configuration for the NuttX > audio driver driver > < c35fd3bb25 boards: cxd56: spresense: add configuration for SDK audio driver > < 502d7bb501 boards: cxd56: spresense: move audio configuration > < b432ae5598 Fix nxstyle warning > < 9131ae1f1f netdev/carrier: monitor the driver status > < 10acadb64b netlink: add netlink route notify support > < 6f1c86d934 netlink: Fix the compiler warning in netlink_add_broadcast > < 9ac3a0d4d8 Fix sixlowpan_framer.c
Re: Start of the NuttX 9.0 release cycle
If we rebase, we would have to update the release notes and related documentation again. You have to freeze the code somewhere; there will always be things that are omitted from the release that will have to wait until the next release. I would vote that we not rebase the release branch. I think we should keep it as stable as possible and only bring in bug fixes. If we get back to a two month release cycle, then that delay is not a big deal. We cannot do meaningful 6 month releases like this one!
Re: Start of the NuttX 9.0 release cycle
Before we vote, how about we rebase the release/9.0 to the latest master? There still have many difference between master and release/9.0: If we rebase, we would have to update the release notes and related documentation again. You have to freeze the code somewhere; there will always be things that are omitted from the release that will have to wait until the next release. I would vote that we not rebase the release branch. I think we should keep it as stable as possible and only bring in bug fixes. The main concern that I have is that there has been no testing or qualification of the release. It was frozen but never verified Greg
Re: Start of the NuttX 9.0 release cycle
The final tag should have a format similar to the old one: nuttx-9.0.0 (or nuttx-9.0.0-rc1 for an RC) The version.sh script needs the "-" to parse the tag. It would seem that if we wanted to make an April 30 release, we should create the tarball now and ask for beta testers. Or do you have some other plan to qualify the release. Can the nightly build be directed to build the releasse branch?
Re: Start of the NuttX 9.0 release cycle
The final tag should have a format similar to the old one: nuttx-9.0.0 (or nuttx-9.0.0-rc1 for an RC) The version.sh script needs the "-" to parse the tag. On Sat, Apr 18, 2020 at 7:52 PM Brennan Ashton wrote: > > Looks good. I'll update my PR now that we have the updated format. I assume > we will apply a tag for the RC and release so we will want to consume that > correctly. I can do that today. > > Happy to upload the signed files to staging when we agree we are all ready > to go. > > --Brennan > > On Sat, Apr 18, 2020, 11:04 AM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > > The patch, however, could be an option. Some files will need to adapt > > > to that though, not only the version.sh script. > > > > I submitted a PR for that. Please take a look. > > (https://github.com/apache/incubator-nuttx/pull/827) > > > > I backported some trivial changes and bugfixes from master to the > > release branch. I guess once the release notes and this PR (if it > > gets merged) are backported we can go ahead and create the tarballs > > then call for a vote. > > > > Brennan, I understand that you have a script to upload the tarballs to > > where they should be. Can you do that once we get everything in > > place? They need to be signed as well. > > > > > > On Thu, Apr 16, 2020 at 2:10 AM Abdelatif Guettouche > > wrote: > > > > > > I don't think we need to expose the RC, it's not the one that's going > > > to be released. > > > The patch, however, could be an option. Some files will need to adapt > > > to that though, not only the version.sh script. > > > > > > > > > On Wed, Apr 15, 2020 at 5:33 PM Brennan Ashton > > > wrote: > > > > > > > > On Wed, Apr 15, 2020, 9:29 AM Abdelatif Guettouche < > > > > abdelatif.guettou...@gmail.com> wrote: > > > > > > > > > > We should probably figure out how this patch would be represented > > in code > > > > > > and if we want to have 9.0.0-RC1 or whatever supported. > > > > > What do you mean in code? > > > > > A release will go through possibly multiple release candidates all > > > > > tagged as 9.0.0-rcX, the final tag will be the same as the last > > > > > accepted RC without the -rc suffix. > > > > > Patches will have to go through the same process. With the voting in > > > > > the incubator general list, etc. > > > > > > > > > > > > > There is a version file that is generated but it only exposes major, > > minor, > > > > and build hash as defines for code to use. Do we need to extend the > > code to > > > > support a patch version? And should the RC be exposed to the code as > > well > > > > somehow (probably less important). > > > > > > > > > > >
Re: Start of the NuttX 9.0 release cycle
Looks good. I'll update my PR now that we have the updated format. I assume we will apply a tag for the RC and release so we will want to consume that correctly. I can do that today. Happy to upload the signed files to staging when we agree we are all ready to go. --Brennan On Sat, Apr 18, 2020, 11:04 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > The patch, however, could be an option. Some files will need to adapt > > to that though, not only the version.sh script. > > I submitted a PR for that. Please take a look. > (https://github.com/apache/incubator-nuttx/pull/827) > > I backported some trivial changes and bugfixes from master to the > release branch. I guess once the release notes and this PR (if it > gets merged) are backported we can go ahead and create the tarballs > then call for a vote. > > Brennan, I understand that you have a script to upload the tarballs to > where they should be. Can you do that once we get everything in > place? They need to be signed as well. > > > On Thu, Apr 16, 2020 at 2:10 AM Abdelatif Guettouche > wrote: > > > > I don't think we need to expose the RC, it's not the one that's going > > to be released. > > The patch, however, could be an option. Some files will need to adapt > > to that though, not only the version.sh script. > > > > > > On Wed, Apr 15, 2020 at 5:33 PM Brennan Ashton > > wrote: > > > > > > On Wed, Apr 15, 2020, 9:29 AM Abdelatif Guettouche < > > > abdelatif.guettou...@gmail.com> wrote: > > > > > > > > We should probably figure out how this patch would be represented > in code > > > > > and if we want to have 9.0.0-RC1 or whatever supported. > > > > What do you mean in code? > > > > A release will go through possibly multiple release candidates all > > > > tagged as 9.0.0-rcX, the final tag will be the same as the last > > > > accepted RC without the -rc suffix. > > > > Patches will have to go through the same process. With the voting in > > > > the incubator general list, etc. > > > > > > > > > > There is a version file that is generated but it only exposes major, > minor, > > > and build hash as defines for code to use. Do we need to extend the > code to > > > support a patch version? And should the RC be exposed to the code as > well > > > somehow (probably less important). > > > > > > > >
Re: Start of the NuttX 9.0 release cycle
> The patch, however, could be an option. Some files will need to adapt > to that though, not only the version.sh script. I submitted a PR for that. Please take a look. (https://github.com/apache/incubator-nuttx/pull/827) I backported some trivial changes and bugfixes from master to the release branch. I guess once the release notes and this PR (if it gets merged) are backported we can go ahead and create the tarballs then call for a vote. Brennan, I understand that you have a script to upload the tarballs to where they should be. Can you do that once we get everything in place? They need to be signed as well. On Thu, Apr 16, 2020 at 2:10 AM Abdelatif Guettouche wrote: > > I don't think we need to expose the RC, it's not the one that's going > to be released. > The patch, however, could be an option. Some files will need to adapt > to that though, not only the version.sh script. > > > On Wed, Apr 15, 2020 at 5:33 PM Brennan Ashton > wrote: > > > > On Wed, Apr 15, 2020, 9:29 AM Abdelatif Guettouche < > > abdelatif.guettou...@gmail.com> wrote: > > > > > > We should probably figure out how this patch would be represented in > > > > code > > > > and if we want to have 9.0.0-RC1 or whatever supported. > > > What do you mean in code? > > > A release will go through possibly multiple release candidates all > > > tagged as 9.0.0-rcX, the final tag will be the same as the last > > > accepted RC without the -rc suffix. > > > Patches will have to go through the same process. With the voting in > > > the incubator general list, etc. > > > > > > > There is a version file that is generated but it only exposes major, minor, > > and build hash as defines for code to use. Do we need to extend the code to > > support a patch version? And should the RC be exposed to the code as well > > somehow (probably less important). > > > > >
Re: Start of the NuttX 9.0 release cycle
I don't think we need to expose the RC, it's not the one that's going to be released. The patch, however, could be an option. Some files will need to adapt to that though, not only the version.sh script. On Wed, Apr 15, 2020 at 5:33 PM Brennan Ashton wrote: > > On Wed, Apr 15, 2020, 9:29 AM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > > We should probably figure out how this patch would be represented in code > > > and if we want to have 9.0.0-RC1 or whatever supported. > > What do you mean in code? > > A release will go through possibly multiple release candidates all > > tagged as 9.0.0-rcX, the final tag will be the same as the last > > accepted RC without the -rc suffix. > > Patches will have to go through the same process. With the voting in > > the incubator general list, etc. > > > > There is a version file that is generated but it only exposes major, minor, > and build hash as defines for code to use. Do we need to extend the code to > support a patch version? And should the RC be exposed to the code as well > somehow (probably less important). > > >
Re: Start of the NuttX 9.0 release cycle
On Wed, Apr 15, 2020, 9:29 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > We should probably figure out how this patch would be represented in code > > and if we want to have 9.0.0-RC1 or whatever supported. > What do you mean in code? > A release will go through possibly multiple release candidates all > tagged as 9.0.0-rcX, the final tag will be the same as the last > accepted RC without the -rc suffix. > Patches will have to go through the same process. With the voting in > the incubator general list, etc. > There is a version file that is generated but it only exposes major, minor, and build hash as defines for code to use. Do we need to extend the code to support a patch version? And should the RC be exposed to the code as well somehow (probably less important). >
Re: Start of the NuttX 9.0 release cycle
I created the branch, it's up to date with master. >From now on, we only backport to the branch what we think is necessary to the release. > We should probably figure out how this patch would be represented in code > and if we want to have 9.0.0-RC1 or whatever supported. What do you mean in code? A release will go through possibly multiple release candidates all tagged as 9.0.0-rcX, the final tag will be the same as the last accepted RC without the -rc suffix. Patches will have to go through the same process. With the voting in the incubator general list, etc. On Mon, Apr 13, 2020 at 12:59 AM Brennan Ashton wrote: > > On Sun, Apr 12, 2020, 4:55 PM Gregory Nutt wrote: > > > > > > With this in mind and with the suggestion from Brennan, the branch > > > would be "releases/9.0.0" > > > > There there would be tags on the branch to differentiate 9.0.1 from > > 9.0.2? and from release candidates? > > > > So would the branch name releases/9.0 still be OK? The tags on the > > branch would pick up the 3rd digit? I don't really care and I am trying > > to leave the decisions in the hands of the people doing the work. No > > need for bossy spectators; no need for spectators period. But I thought > > I should mention that. > > > > Greg > > > > This all seems very reasonable to me. No need to bikeshed too much, we can > always learn from the release and refine as we go along. > > We should probably figure out how this patch would be represented in code > and if we want to have 9.0.0-RC1 or whatever supported. > > >
Re: Start of the NuttX 9.0 release cycle
On Sun, Apr 12, 2020, 4:55 PM Gregory Nutt wrote: > > > With this in mind and with the suggestion from Brennan, the branch > > would be "releases/9.0.0" > > There there would be tags on the branch to differentiate 9.0.1 from > 9.0.2? and from release candidates? > > So would the branch name releases/9.0 still be OK? The tags on the > branch would pick up the 3rd digit? I don't really care and I am trying > to leave the decisions in the hands of the people doing the work. No > need for bossy spectators; no need for spectators period. But I thought > I should mention that. > > Greg > This all seems very reasonable to me. No need to bikeshed too much, we can always learn from the release and refine as we go along. We should probably figure out how this patch would be represented in code and if we want to have 9.0.0-RC1 or whatever supported. >
Re: Start of the NuttX 9.0 release cycle
With this in mind and with the suggestion from Brennan, the branch would be "releases/9.0.0" There there would be tags on the branch to differentiate 9.0.1 from 9.0.2? and from release candidates? So would the branch name releases/9.0 still be OK? The tags on the branch would pick up the 3rd digit? I don't really care and I am trying to leave the decisions in the hands of the people doing the work. No need for bossy spectators; no need for spectators period. But I thought I should mention that. Greg
Re: Start of the NuttX 9.0 release cycle
Another point that was brought to my attention and that we overlooked, is the new release versioning. In the early discussions about the release it was agreed on extending the versioning to 3 numbers: major, minor, patch. Ex. 9.0.0 In the past, if a bug was found after a release, a separate file containing a patch fix was distributed. What we want to do now is to fix the bug and re-release incrementing the patch number, 9.0.1 for example. With this in mind and with the suggestion from Brennan, the branch would be "releases/9.0.0" It has been almost a week since we created the branch, some PRs were contributed in the meantime. I think all those contributions are worthy to get incorporated in the release. So, I suggest to delete the old branch and create a new branch "releases/9.0.0" from master. On Fri, Apr 10, 2020 at 9:56 PM Abdelatif Guettouche wrote: > > I think we still need some organization before creating the PR. Mainly > the driver section, I think it should be divided for all other > subsystems. > > But, please, let's take this conversation to the Release Note thread. > I'm still trying to get everyone's opinion on the branch naming convention. > > On Fri, Apr 10, 2020 at 8:12 PM Adam Feuer wrote: > > > > Ok, I went through PRs 466-764 for bugfixes, and added a few to the wiki > > page. Many of the improvements were changes to conform to style, or small > > fixes that would not be relevant for release notes. > > > > I think we're done summarizing. Are we ready to create a PR for the Release > > Notes? In other words, get them into the text file form? > > > > cheers > > adam > > > > On Fri, Apr 10, 2020 at 11:58 AM Alan Carvalho de Assis > > wrote: > > > > > No problem, I didn't realize that you didn't include the previous > > > commit after reviewing all PRs. > > > > > > I think now we have a better picture about all improvements and > > > bugfixes from 8.2 to 9.0. > > > > > > BR, > > > > > > Alan > > > > > > On 4/10/20, Adam Feuer wrote: > > > > Ok thanks Alan. I'm sorry I wasn't clear about what we had done. > > > > > > > > -adam > > > > > > > > On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis < > > > acas...@gmail.com> > > > > wrote: > > > > > > > >> Hi Adam, > > > >> > > > >> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0 > > > >> tag. But I didn't checked for improvements because I thought you, > > > >> Nathan and Abdelatif did it. > > > >> > > > >> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no > > > >> problem. > > > >> > > > >> BR, > > > >> > > > >> Alan > > > >> > > > >> On 4/10/20, Adam Feuer wrote: > > > >> > Alan, > > > >> > > > > >> > Next we need to check for features/improvements and bugfixes between > > > 23 > > > >> > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the > > > 16 > > > >> > November 2019, the date of NuttX release 8.2. The main source of info > > > >> > for > > > >> > this would be commit messages in the current master branch. > > > >> > > > > >> > Would you be willing to look through those? Or figure out a way to > > > >> > divide > > > >> > them up among you, me, Nathan, and Abdelatif? > > > >> > > > > >> > -adam > > > >> > > > > >> > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis < > > > >> acas...@gmail.com> > > > >> > wrote: > > > >> > > > > >> >> Hi guys, > > > >> >> > > > >> >> I finished including the apps/ improvements and bugfixes. > > > >> >> > > > >> >> Is there anything else we need to take care? > > > >> >> > > > >> >> BR, > > > >> >> > > > >> >> Alan > > > >> >> > > > >> >> On 4/10/20, Abdelatif Guettouche > > > >> wrote: > > > >> >> >> Speaking about the branch, Brennan is suggesting to have a > > > >> >> >> different > > > >> >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY > > > >> >> >> (the > > > >> >> >> reasons behind this are here: > > > >> >> >> https://github.com/apache/incubator-nuttx/pull/757) > > > >> >> > > > > >> >> > Is everyone okay with changing the branches naming convention? > > > >> >> > I personally do not mind. > > > >> >> > > > > >> >> > For that PR, I asked Brennan on how to proceed with signing the > > > >> >> > tarballs. > > > >> >> > The original flow was: > > > >> >> > 1. Generate the tarballs > > > >> >> > 2. Sign the tarballs and create the hashes. > > > >> >> > 3. Then upload everything (tarballs, hashes, signatures) > > > >> >> > Everything was done locally and then uploaded. > > > >> >> > With the PR757 the release tarballs are generated with a push to > > > the > > > >> >> > release branch. > > > >> >> > Do we download them, sign and then upload the signatures? > > > >> >> > We need at least one way to check the downloads before signing, > > > like > > > >> >> > by creating the hashes with the tarballs. > > > >> >> > > > > >> >> > > > > >> >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer > > > wrote: > > > >> >> >> > > > >> >> >> Xiang, > > > >> >> >> > > > >> >> >> Ok, thanks. It's great that this doesn't
Re: Start of the NuttX 9.0 release cycle
I think we still need some organization before creating the PR. Mainly the driver section, I think it should be divided for all other subsystems. But, please, let's take this conversation to the Release Note thread. I'm still trying to get everyone's opinion on the branch naming convention. On Fri, Apr 10, 2020 at 8:12 PM Adam Feuer wrote: > > Ok, I went through PRs 466-764 for bugfixes, and added a few to the wiki > page. Many of the improvements were changes to conform to style, or small > fixes that would not be relevant for release notes. > > I think we're done summarizing. Are we ready to create a PR for the Release > Notes? In other words, get them into the text file form? > > cheers > adam > > On Fri, Apr 10, 2020 at 11:58 AM Alan Carvalho de Assis > wrote: > > > No problem, I didn't realize that you didn't include the previous > > commit after reviewing all PRs. > > > > I think now we have a better picture about all improvements and > > bugfixes from 8.2 to 9.0. > > > > BR, > > > > Alan > > > > On 4/10/20, Adam Feuer wrote: > > > Ok thanks Alan. I'm sorry I wasn't clear about what we had done. > > > > > > -adam > > > > > > On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis < > > acas...@gmail.com> > > > wrote: > > > > > >> Hi Adam, > > >> > > >> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0 > > >> tag. But I didn't checked for improvements because I thought you, > > >> Nathan and Abdelatif did it. > > >> > > >> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no > > >> problem. > > >> > > >> BR, > > >> > > >> Alan > > >> > > >> On 4/10/20, Adam Feuer wrote: > > >> > Alan, > > >> > > > >> > Next we need to check for features/improvements and bugfixes between > > 23 > > >> > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the > > 16 > > >> > November 2019, the date of NuttX release 8.2. The main source of info > > >> > for > > >> > this would be commit messages in the current master branch. > > >> > > > >> > Would you be willing to look through those? Or figure out a way to > > >> > divide > > >> > them up among you, me, Nathan, and Abdelatif? > > >> > > > >> > -adam > > >> > > > >> > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis < > > >> acas...@gmail.com> > > >> > wrote: > > >> > > > >> >> Hi guys, > > >> >> > > >> >> I finished including the apps/ improvements and bugfixes. > > >> >> > > >> >> Is there anything else we need to take care? > > >> >> > > >> >> BR, > > >> >> > > >> >> Alan > > >> >> > > >> >> On 4/10/20, Abdelatif Guettouche > > >> wrote: > > >> >> >> Speaking about the branch, Brennan is suggesting to have a > > >> >> >> different > > >> >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY > > >> >> >> (the > > >> >> >> reasons behind this are here: > > >> >> >> https://github.com/apache/incubator-nuttx/pull/757) > > >> >> > > > >> >> > Is everyone okay with changing the branches naming convention? > > >> >> > I personally do not mind. > > >> >> > > > >> >> > For that PR, I asked Brennan on how to proceed with signing the > > >> >> > tarballs. > > >> >> > The original flow was: > > >> >> > 1. Generate the tarballs > > >> >> > 2. Sign the tarballs and create the hashes. > > >> >> > 3. Then upload everything (tarballs, hashes, signatures) > > >> >> > Everything was done locally and then uploaded. > > >> >> > With the PR757 the release tarballs are generated with a push to > > the > > >> >> > release branch. > > >> >> > Do we download them, sign and then upload the signatures? > > >> >> > We need at least one way to check the downloads before signing, > > like > > >> >> > by creating the hashes with the tarballs. > > >> >> > > > >> >> > > > >> >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer > > wrote: > > >> >> >> > > >> >> >> Xiang, > > >> >> >> > > >> >> >> Ok, thanks. It's great that this doesn't block the release! > > >> >> >> > > >> >> >> -adam > > >> >> >> > > >> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao > > >> >> >> > >> > > > >> >> >> wrote: > > >> >> >> > > >> >> >> > This build error happen for several special config only, and > > >> already > > >> >> >> > exist > > >> >> >> > > > >> >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer > > >> wrote: > > >> >> >> > > > > >> >> >> > > Xiang, > > >> >> >> > > > > >> >> >> > > Do the parallel build failures block our release? If so, what > > >> >> >> > > can > > >> >> >> > > we > > >> >> >> > > do > > >> >> >> > > > >> >> >> > Shouldn't, because: > > >> >> >> > 1.The build error already exist for a long time > > >> >> >> > 2.Only several seldom used configs(all related to > > >> >> >> > binfmt/module/so) > > >> >> >> > hit this issue > > >> >> >> > 3.The single thread build can always finish successfully > > >> >> >> > > > >> >> >> > > temporarily to unblock it? Or is there a fix in the works that > > >> >> >> > > will > > >> >> >> > > be > > >> >> >> > > ready soon? > > >> >> >> > > > > >> >> >> > > > >> >> >> > Masayuki,
Re: Start of the NuttX 9.0 release cycle
Ok, I went through PRs 466-764 for bugfixes, and added a few to the wiki page. Many of the improvements were changes to conform to style, or small fixes that would not be relevant for release notes. I think we're done summarizing. Are we ready to create a PR for the Release Notes? In other words, get them into the text file form? cheers adam On Fri, Apr 10, 2020 at 11:58 AM Alan Carvalho de Assis wrote: > No problem, I didn't realize that you didn't include the previous > commit after reviewing all PRs. > > I think now we have a better picture about all improvements and > bugfixes from 8.2 to 9.0. > > BR, > > Alan > > On 4/10/20, Adam Feuer wrote: > > Ok thanks Alan. I'm sorry I wasn't clear about what we had done. > > > > -adam > > > > On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis < > acas...@gmail.com> > > wrote: > > > >> Hi Adam, > >> > >> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0 > >> tag. But I didn't checked for improvements because I thought you, > >> Nathan and Abdelatif did it. > >> > >> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no > >> problem. > >> > >> BR, > >> > >> Alan > >> > >> On 4/10/20, Adam Feuer wrote: > >> > Alan, > >> > > >> > Next we need to check for features/improvements and bugfixes between > 23 > >> > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the > 16 > >> > November 2019, the date of NuttX release 8.2. The main source of info > >> > for > >> > this would be commit messages in the current master branch. > >> > > >> > Would you be willing to look through those? Or figure out a way to > >> > divide > >> > them up among you, me, Nathan, and Abdelatif? > >> > > >> > -adam > >> > > >> > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis < > >> acas...@gmail.com> > >> > wrote: > >> > > >> >> Hi guys, > >> >> > >> >> I finished including the apps/ improvements and bugfixes. > >> >> > >> >> Is there anything else we need to take care? > >> >> > >> >> BR, > >> >> > >> >> Alan > >> >> > >> >> On 4/10/20, Abdelatif Guettouche > >> wrote: > >> >> >> Speaking about the branch, Brennan is suggesting to have a > >> >> >> different > >> >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY > >> >> >> (the > >> >> >> reasons behind this are here: > >> >> >> https://github.com/apache/incubator-nuttx/pull/757) > >> >> > > >> >> > Is everyone okay with changing the branches naming convention? > >> >> > I personally do not mind. > >> >> > > >> >> > For that PR, I asked Brennan on how to proceed with signing the > >> >> > tarballs. > >> >> > The original flow was: > >> >> > 1. Generate the tarballs > >> >> > 2. Sign the tarballs and create the hashes. > >> >> > 3. Then upload everything (tarballs, hashes, signatures) > >> >> > Everything was done locally and then uploaded. > >> >> > With the PR757 the release tarballs are generated with a push to > the > >> >> > release branch. > >> >> > Do we download them, sign and then upload the signatures? > >> >> > We need at least one way to check the downloads before signing, > like > >> >> > by creating the hashes with the tarballs. > >> >> > > >> >> > > >> >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer > wrote: > >> >> >> > >> >> >> Xiang, > >> >> >> > >> >> >> Ok, thanks. It's great that this doesn't block the release! > >> >> >> > >> >> >> -adam > >> >> >> > >> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao > >> >> >> >> > > >> >> >> wrote: > >> >> >> > >> >> >> > This build error happen for several special config only, and > >> already > >> >> >> > exist > >> >> >> > > >> >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer > >> wrote: > >> >> >> > > > >> >> >> > > Xiang, > >> >> >> > > > >> >> >> > > Do the parallel build failures block our release? If so, what > >> >> >> > > can > >> >> >> > > we > >> >> >> > > do > >> >> >> > > >> >> >> > Shouldn't, because: > >> >> >> > 1.The build error already exist for a long time > >> >> >> > 2.Only several seldom used configs(all related to > >> >> >> > binfmt/module/so) > >> >> >> > hit this issue > >> >> >> > 3.The single thread build can always finish successfully > >> >> >> > > >> >> >> > > temporarily to unblock it? Or is there a fix in the works that > >> >> >> > > will > >> >> >> > > be > >> >> >> > > ready soon? > >> >> >> > > > >> >> >> > > >> >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the > >> >> >> > recent > >> >> >> > month, some issue get fixed, but some need more time to > >> investigate. > >> >> >> > > >> >> >> > > -adam > >> >> >> > > > >> >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < > >> >> xiaoxiang781...@gmail.com> > >> >> >> > wrote: > >> >> >> > > > >> >> >> > > > At least, the parallel build still fail randomly which block > >> our > >> >> >> > > > nightly checker. > >> >> >> > > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> Adam Feuer > >> >> > > >> >> > >> > > >> > > >> > -- > >> > Adam Feuer > >> > > >> > > > > > > -- > > Adam Feuer > > >
Re: Start of the NuttX 9.0 release cycle
No problem, I didn't realize that you didn't include the previous commit after reviewing all PRs. I think now we have a better picture about all improvements and bugfixes from 8.2 to 9.0. BR, Alan On 4/10/20, Adam Feuer wrote: > Ok thanks Alan. I'm sorry I wasn't clear about what we had done. > > -adam > > On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis > wrote: > >> Hi Adam, >> >> Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0 >> tag. But I didn't checked for improvements because I thought you, >> Nathan and Abdelatif did it. >> >> I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no >> problem. >> >> BR, >> >> Alan >> >> On 4/10/20, Adam Feuer wrote: >> > Alan, >> > >> > Next we need to check for features/improvements and bugfixes between 23 >> > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 >> > November 2019, the date of NuttX release 8.2. The main source of info >> > for >> > this would be commit messages in the current master branch. >> > >> > Would you be willing to look through those? Or figure out a way to >> > divide >> > them up among you, me, Nathan, and Abdelatif? >> > >> > -adam >> > >> > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis < >> acas...@gmail.com> >> > wrote: >> > >> >> Hi guys, >> >> >> >> I finished including the apps/ improvements and bugfixes. >> >> >> >> Is there anything else we need to take care? >> >> >> >> BR, >> >> >> >> Alan >> >> >> >> On 4/10/20, Abdelatif Guettouche >> wrote: >> >> >> Speaking about the branch, Brennan is suggesting to have a >> >> >> different >> >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY >> >> >> (the >> >> >> reasons behind this are here: >> >> >> https://github.com/apache/incubator-nuttx/pull/757) >> >> > >> >> > Is everyone okay with changing the branches naming convention? >> >> > I personally do not mind. >> >> > >> >> > For that PR, I asked Brennan on how to proceed with signing the >> >> > tarballs. >> >> > The original flow was: >> >> > 1. Generate the tarballs >> >> > 2. Sign the tarballs and create the hashes. >> >> > 3. Then upload everything (tarballs, hashes, signatures) >> >> > Everything was done locally and then uploaded. >> >> > With the PR757 the release tarballs are generated with a push to the >> >> > release branch. >> >> > Do we download them, sign and then upload the signatures? >> >> > We need at least one way to check the downloads before signing, like >> >> > by creating the hashes with the tarballs. >> >> > >> >> > >> >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: >> >> >> >> >> >> Xiang, >> >> >> >> >> >> Ok, thanks. It's great that this doesn't block the release! >> >> >> >> >> >> -adam >> >> >> >> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao >> >> >> > > >> >> >> wrote: >> >> >> >> >> >> > This build error happen for several special config only, and >> already >> >> >> > exist >> >> >> > >> >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer >> wrote: >> >> >> > > >> >> >> > > Xiang, >> >> >> > > >> >> >> > > Do the parallel build failures block our release? If so, what >> >> >> > > can >> >> >> > > we >> >> >> > > do >> >> >> > >> >> >> > Shouldn't, because: >> >> >> > 1.The build error already exist for a long time >> >> >> > 2.Only several seldom used configs(all related to >> >> >> > binfmt/module/so) >> >> >> > hit this issue >> >> >> > 3.The single thread build can always finish successfully >> >> >> > >> >> >> > > temporarily to unblock it? Or is there a fix in the works that >> >> >> > > will >> >> >> > > be >> >> >> > > ready soon? >> >> >> > > >> >> >> > >> >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the >> >> >> > recent >> >> >> > month, some issue get fixed, but some need more time to >> investigate. >> >> >> > >> >> >> > > -adam >> >> >> > > >> >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < >> >> xiaoxiang781...@gmail.com> >> >> >> > wrote: >> >> >> > > >> >> >> > > > At least, the parallel build still fail randomly which block >> our >> >> >> > > > nightly checker. >> >> >> > >> >> >> >> >> >> >> >> >> -- >> >> >> Adam Feuer >> >> > >> >> >> > >> > >> > -- >> > Adam Feuer >> > >> > > > -- > Adam Feuer >
Re: Start of the NuttX 9.0 release cycle
Ok thanks Alan. I'm sorry I wasn't clear about what we had done. -adam On Fri, Apr 10, 2020 at 11:27 AM Alan Carvalho de Assis wrote: > Hi Adam, > > Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0 > tag. But I didn't checked for improvements because I thought you, > Nathan and Abdelatif did it. > > I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no > problem. > > BR, > > Alan > > On 4/10/20, Adam Feuer wrote: > > Alan, > > > > Next we need to check for features/improvements and bugfixes between 23 > > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 > > November 2019, the date of NuttX release 8.2. The main source of info for > > this would be commit messages in the current master branch. > > > > Would you be willing to look through those? Or figure out a way to divide > > them up among you, me, Nathan, and Abdelatif? > > > > -adam > > > > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis < > acas...@gmail.com> > > wrote: > > > >> Hi guys, > >> > >> I finished including the apps/ improvements and bugfixes. > >> > >> Is there anything else we need to take care? > >> > >> BR, > >> > >> Alan > >> > >> On 4/10/20, Abdelatif Guettouche > wrote: > >> >> Speaking about the branch, Brennan is suggesting to have a different > >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the > >> >> reasons behind this are here: > >> >> https://github.com/apache/incubator-nuttx/pull/757) > >> > > >> > Is everyone okay with changing the branches naming convention? > >> > I personally do not mind. > >> > > >> > For that PR, I asked Brennan on how to proceed with signing the > >> > tarballs. > >> > The original flow was: > >> > 1. Generate the tarballs > >> > 2. Sign the tarballs and create the hashes. > >> > 3. Then upload everything (tarballs, hashes, signatures) > >> > Everything was done locally and then uploaded. > >> > With the PR757 the release tarballs are generated with a push to the > >> > release branch. > >> > Do we download them, sign and then upload the signatures? > >> > We need at least one way to check the downloads before signing, like > >> > by creating the hashes with the tarballs. > >> > > >> > > >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: > >> >> > >> >> Xiang, > >> >> > >> >> Ok, thanks. It's great that this doesn't block the release! > >> >> > >> >> -adam > >> >> > >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao > > >> >> wrote: > >> >> > >> >> > This build error happen for several special config only, and > already > >> >> > exist > >> >> > > >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer > wrote: > >> >> > > > >> >> > > Xiang, > >> >> > > > >> >> > > Do the parallel build failures block our release? If so, what can > >> >> > > we > >> >> > > do > >> >> > > >> >> > Shouldn't, because: > >> >> > 1.The build error already exist for a long time > >> >> > 2.Only several seldom used configs(all related to binfmt/module/so) > >> >> > hit this issue > >> >> > 3.The single thread build can always finish successfully > >> >> > > >> >> > > temporarily to unblock it? Or is there a fix in the works that > >> >> > > will > >> >> > > be > >> >> > > ready soon? > >> >> > > > >> >> > > >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the > >> >> > recent > >> >> > month, some issue get fixed, but some need more time to > investigate. > >> >> > > >> >> > > -adam > >> >> > > > >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < > >> xiaoxiang781...@gmail.com> > >> >> > wrote: > >> >> > > > >> >> > > > At least, the parallel build still fail randomly which block > our > >> >> > > > nightly checker. > >> >> > > >> >> > >> >> > >> >> -- > >> >> Adam Feuer > >> > > >> > > > > > > -- > > Adam Feuer > > > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
Ok, done! On 4/10/20, Alan Carvalho de Assis wrote: > Hi Adam, > > Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0 > tag. But I didn't checked for improvements because I thought you, > Nathan and Abdelatif did it. > > I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no > problem. > > BR, > > Alan > > On 4/10/20, Adam Feuer wrote: >> Alan, >> >> Next we need to check for features/improvements and bugfixes between 23 >> December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 >> November 2019, the date of NuttX release 8.2. The main source of info for >> this would be commit messages in the current master branch. >> >> Would you be willing to look through those? Or figure out a way to divide >> them up among you, me, Nathan, and Abdelatif? >> >> -adam >> >> On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis >> >> wrote: >> >>> Hi guys, >>> >>> I finished including the apps/ improvements and bugfixes. >>> >>> Is there anything else we need to take care? >>> >>> BR, >>> >>> Alan >>> >>> On 4/10/20, Abdelatif Guettouche wrote: >>> >> Speaking about the branch, Brennan is suggesting to have a different >>> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the >>> >> reasons behind this are here: >>> >> https://github.com/apache/incubator-nuttx/pull/757) >>> > >>> > Is everyone okay with changing the branches naming convention? >>> > I personally do not mind. >>> > >>> > For that PR, I asked Brennan on how to proceed with signing the >>> > tarballs. >>> > The original flow was: >>> > 1. Generate the tarballs >>> > 2. Sign the tarballs and create the hashes. >>> > 3. Then upload everything (tarballs, hashes, signatures) >>> > Everything was done locally and then uploaded. >>> > With the PR757 the release tarballs are generated with a push to the >>> > release branch. >>> > Do we download them, sign and then upload the signatures? >>> > We need at least one way to check the downloads before signing, like >>> > by creating the hashes with the tarballs. >>> > >>> > >>> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: >>> >> >>> >> Xiang, >>> >> >>> >> Ok, thanks. It's great that this doesn't block the release! >>> >> >>> >> -adam >>> >> >>> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao >>> >> wrote: >>> >> >>> >> > This build error happen for several special config only, and >>> >> > already >>> >> > exist >>> >> > >>> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer >>> >> > wrote: >>> >> > > >>> >> > > Xiang, >>> >> > > >>> >> > > Do the parallel build failures block our release? If so, what can >>> >> > > we >>> >> > > do >>> >> > >>> >> > Shouldn't, because: >>> >> > 1.The build error already exist for a long time >>> >> > 2.Only several seldom used configs(all related to binfmt/module/so) >>> >> > hit this issue >>> >> > 3.The single thread build can always finish successfully >>> >> > >>> >> > > temporarily to unblock it? Or is there a fix in the works that >>> >> > > will >>> >> > > be >>> >> > > ready soon? >>> >> > > >>> >> > >>> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the >>> >> > recent >>> >> > month, some issue get fixed, but some need more time to >>> >> > investigate. >>> >> > >>> >> > > -adam >>> >> > > >>> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < >>> xiaoxiang781...@gmail.com> >>> >> > wrote: >>> >> > > >>> >> > > > At least, the parallel build still fail randomly which block >>> >> > > > our >>> >> > > > nightly checker. >>> >> > >>> >> >>> >> >>> >> -- >>> >> Adam Feuer >>> > >>> >> >> >> -- >> Adam Feuer >> >
Re: Start of the NuttX 9.0 release cycle
Hi Adam, Yesterday I passed all the bugfixes from nuttx-8.2 until nuttx-9.0 tag. But I didn't checked for improvements because I thought you, Nathan and Abdelatif did it. I can do it for the improvements from nuttx-8.2 until Nov. 23 2019, no problem. BR, Alan On 4/10/20, Adam Feuer wrote: > Alan, > > Next we need to check for features/improvements and bugfixes between 23 > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 > November 2019, the date of NuttX release 8.2. The main source of info for > this would be commit messages in the current master branch. > > Would you be willing to look through those? Or figure out a way to divide > them up among you, me, Nathan, and Abdelatif? > > -adam > > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis > wrote: > >> Hi guys, >> >> I finished including the apps/ improvements and bugfixes. >> >> Is there anything else we need to take care? >> >> BR, >> >> Alan >> >> On 4/10/20, Abdelatif Guettouche wrote: >> >> Speaking about the branch, Brennan is suggesting to have a different >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the >> >> reasons behind this are here: >> >> https://github.com/apache/incubator-nuttx/pull/757) >> > >> > Is everyone okay with changing the branches naming convention? >> > I personally do not mind. >> > >> > For that PR, I asked Brennan on how to proceed with signing the >> > tarballs. >> > The original flow was: >> > 1. Generate the tarballs >> > 2. Sign the tarballs and create the hashes. >> > 3. Then upload everything (tarballs, hashes, signatures) >> > Everything was done locally and then uploaded. >> > With the PR757 the release tarballs are generated with a push to the >> > release branch. >> > Do we download them, sign and then upload the signatures? >> > We need at least one way to check the downloads before signing, like >> > by creating the hashes with the tarballs. >> > >> > >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: >> >> >> >> Xiang, >> >> >> >> Ok, thanks. It's great that this doesn't block the release! >> >> >> >> -adam >> >> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao >> >> wrote: >> >> >> >> > This build error happen for several special config only, and already >> >> > exist >> >> > >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: >> >> > > >> >> > > Xiang, >> >> > > >> >> > > Do the parallel build failures block our release? If so, what can >> >> > > we >> >> > > do >> >> > >> >> > Shouldn't, because: >> >> > 1.The build error already exist for a long time >> >> > 2.Only several seldom used configs(all related to binfmt/module/so) >> >> > hit this issue >> >> > 3.The single thread build can always finish successfully >> >> > >> >> > > temporarily to unblock it? Or is there a fix in the works that >> >> > > will >> >> > > be >> >> > > ready soon? >> >> > > >> >> > >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the >> >> > recent >> >> > month, some issue get fixed, but some need more time to investigate. >> >> > >> >> > > -adam >> >> > > >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < >> xiaoxiang781...@gmail.com> >> >> > wrote: >> >> > > >> >> > > > At least, the parallel build still fail randomly which block our >> >> > > > nightly checker. >> >> > >> >> >> >> >> >> -- >> >> Adam Feuer >> > >> > > > -- > Adam Feuer >
Re: Start of the NuttX 9.0 release cycle
On Fri, Apr 10, 2020 at 1:44 PM Adam Feuer wrote: > Next we need to check for features/improvements and bugfixes between 23 > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 > November 2019, the date of NuttX release 8.2. The main source of info for > this would be commit messages in the current master branch. > > Would you be willing to look through those? Or figure out a way to divide > them up among you, me, Nathan, and Abdelatif? Let's split them up 3 ways. Is this incantation producing the correct range? git log --since 2019/11/16 --until 2019/12/23 --oneline Asking because this would seem to indicate otherwise: https://stackoverflow.com/questions/37311494/how-to-get-git-to-show-commits-in-a-specified-date-range-for-author-date Thanks, Nathan
Re: Start of the NuttX 9.0 release cycle
P.S. I think this would have to be done for both nuttx and nuttx-apps. On Fri, Apr 10, 2020 at 10:43 AM Adam Feuer wrote: > Alan, > > Next we need to check for features/improvements and bugfixes between 23 > December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 > November 2019, the date of NuttX release 8.2. The main source of info for > this would be commit messages in the current master branch. > > Would you be willing to look through those? Or figure out a way to divide > them up among you, me, Nathan, and Abdelatif? > > -adam > > On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis > wrote: > >> Hi guys, >> >> I finished including the apps/ improvements and bugfixes. >> >> Is there anything else we need to take care? >> >> BR, >> >> Alan >> >> On 4/10/20, Abdelatif Guettouche wrote: >> >> Speaking about the branch, Brennan is suggesting to have a different >> >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the >> >> reasons behind this are here: >> >> https://github.com/apache/incubator-nuttx/pull/757) >> > >> > Is everyone okay with changing the branches naming convention? >> > I personally do not mind. >> > >> > For that PR, I asked Brennan on how to proceed with signing the >> tarballs. >> > The original flow was: >> > 1. Generate the tarballs >> > 2. Sign the tarballs and create the hashes. >> > 3. Then upload everything (tarballs, hashes, signatures) >> > Everything was done locally and then uploaded. >> > With the PR757 the release tarballs are generated with a push to the >> > release branch. >> > Do we download them, sign and then upload the signatures? >> > We need at least one way to check the downloads before signing, like >> > by creating the hashes with the tarballs. >> > >> > >> > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: >> >> >> >> Xiang, >> >> >> >> Ok, thanks. It's great that this doesn't block the release! >> >> >> >> -adam >> >> >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao >> >> wrote: >> >> >> >> > This build error happen for several special config only, and already >> >> > exist >> >> > >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: >> >> > > >> >> > > Xiang, >> >> > > >> >> > > Do the parallel build failures block our release? If so, what can >> we >> >> > > do >> >> > >> >> > Shouldn't, because: >> >> > 1.The build error already exist for a long time >> >> > 2.Only several seldom used configs(all related to binfmt/module/so) >> >> > hit this issue >> >> > 3.The single thread build can always finish successfully >> >> > >> >> > > temporarily to unblock it? Or is there a fix in the works that will >> >> > > be >> >> > > ready soon? >> >> > > >> >> > >> >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent >> >> > month, some issue get fixed, but some need more time to investigate. >> >> > >> >> > > -adam >> >> > > >> >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < >> xiaoxiang781...@gmail.com> >> >> > wrote: >> >> > > >> >> > > > At least, the parallel build still fail randomly which block our >> >> > > > nightly checker. >> >> > >> >> >> >> >> >> -- >> >> Adam Feuer >> > >> > > > -- > Adam Feuer > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
Alan, Next we need to check for features/improvements and bugfixes between 23 December 2019 (1st PR in github.com/apache/incubator-nuttx) and the 16 November 2019, the date of NuttX release 8.2. The main source of info for this would be commit messages in the current master branch. Would you be willing to look through those? Or figure out a way to divide them up among you, me, Nathan, and Abdelatif? -adam On Fri, Apr 10, 2020 at 10:05 AM Alan Carvalho de Assis wrote: > Hi guys, > > I finished including the apps/ improvements and bugfixes. > > Is there anything else we need to take care? > > BR, > > Alan > > On 4/10/20, Abdelatif Guettouche wrote: > >> Speaking about the branch, Brennan is suggesting to have a different > >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the > >> reasons behind this are here: > >> https://github.com/apache/incubator-nuttx/pull/757) > > > > Is everyone okay with changing the branches naming convention? > > I personally do not mind. > > > > For that PR, I asked Brennan on how to proceed with signing the tarballs. > > The original flow was: > > 1. Generate the tarballs > > 2. Sign the tarballs and create the hashes. > > 3. Then upload everything (tarballs, hashes, signatures) > > Everything was done locally and then uploaded. > > With the PR757 the release tarballs are generated with a push to the > > release branch. > > Do we download them, sign and then upload the signatures? > > We need at least one way to check the downloads before signing, like > > by creating the hashes with the tarballs. > > > > > > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: > >> > >> Xiang, > >> > >> Ok, thanks. It's great that this doesn't block the release! > >> > >> -adam > >> > >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao > >> wrote: > >> > >> > This build error happen for several special config only, and already > >> > exist > >> > > >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: > >> > > > >> > > Xiang, > >> > > > >> > > Do the parallel build failures block our release? If so, what can we > >> > > do > >> > > >> > Shouldn't, because: > >> > 1.The build error already exist for a long time > >> > 2.Only several seldom used configs(all related to binfmt/module/so) > >> > hit this issue > >> > 3.The single thread build can always finish successfully > >> > > >> > > temporarily to unblock it? Or is there a fix in the works that will > >> > > be > >> > > ready soon? > >> > > > >> > > >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent > >> > month, some issue get fixed, but some need more time to investigate. > >> > > >> > > -adam > >> > > > >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao < > xiaoxiang781...@gmail.com> > >> > wrote: > >> > > > >> > > > At least, the parallel build still fail randomly which block our > >> > > > nightly checker. > >> > > >> > >> > >> -- > >> Adam Feuer > > > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
Hi guys, I finished including the apps/ improvements and bugfixes. Is there anything else we need to take care? BR, Alan On 4/10/20, Abdelatif Guettouche wrote: >> Speaking about the branch, Brennan is suggesting to have a different >> naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the >> reasons behind this are here: >> https://github.com/apache/incubator-nuttx/pull/757) > > Is everyone okay with changing the branches naming convention? > I personally do not mind. > > For that PR, I asked Brennan on how to proceed with signing the tarballs. > The original flow was: > 1. Generate the tarballs > 2. Sign the tarballs and create the hashes. > 3. Then upload everything (tarballs, hashes, signatures) > Everything was done locally and then uploaded. > With the PR757 the release tarballs are generated with a push to the > release branch. > Do we download them, sign and then upload the signatures? > We need at least one way to check the downloads before signing, like > by creating the hashes with the tarballs. > > > On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: >> >> Xiang, >> >> Ok, thanks. It's great that this doesn't block the release! >> >> -adam >> >> On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao >> wrote: >> >> > This build error happen for several special config only, and already >> > exist >> > >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: >> > > >> > > Xiang, >> > > >> > > Do the parallel build failures block our release? If so, what can we >> > > do >> > >> > Shouldn't, because: >> > 1.The build error already exist for a long time >> > 2.Only several seldom used configs(all related to binfmt/module/so) >> > hit this issue >> > 3.The single thread build can always finish successfully >> > >> > > temporarily to unblock it? Or is there a fix in the works that will >> > > be >> > > ready soon? >> > > >> > >> > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent >> > month, some issue get fixed, but some need more time to investigate. >> > >> > > -adam >> > > >> > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao >> > wrote: >> > > >> > > > At least, the parallel build still fail randomly which block our >> > > > nightly checker. >> > >> >> >> -- >> Adam Feuer >
Re: Start of the NuttX 9.0 release cycle
> Speaking about the branch, Brennan is suggesting to have a different > naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the > reasons behind this are here: > https://github.com/apache/incubator-nuttx/pull/757) Is everyone okay with changing the branches naming convention? I personally do not mind. For that PR, I asked Brennan on how to proceed with signing the tarballs. The original flow was: 1. Generate the tarballs 2. Sign the tarballs and create the hashes. 3. Then upload everything (tarballs, hashes, signatures) Everything was done locally and then uploaded. With the PR757 the release tarballs are generated with a push to the release branch. Do we download them, sign and then upload the signatures? We need at least one way to check the downloads before signing, like by creating the hashes with the tarballs. On Fri, Apr 10, 2020 at 4:41 AM Adam Feuer wrote: > > Xiang, > > Ok, thanks. It's great that this doesn't block the release! > > -adam > > On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao wrote: > > > This build error happen for several special config only, and already exist > > > > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: > > > > > > Xiang, > > > > > > Do the parallel build failures block our release? If so, what can we do > > > > Shouldn't, because: > > 1.The build error already exist for a long time > > 2.Only several seldom used configs(all related to binfmt/module/so) > > hit this issue > > 3.The single thread build can always finish successfully > > > > > temporarily to unblock it? Or is there a fix in the works that will be > > > ready soon? > > > > > > > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent > > month, some issue get fixed, but some need more time to investigate. > > > > > -adam > > > > > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao > > wrote: > > > > > > > At least, the parallel build still fail randomly which block our > > > > nightly checker. > > > > > -- > Adam Feuer
Re: Start of the NuttX 9.0 release cycle
Xiang, Ok, thanks. It's great that this doesn't block the release! -adam On Thu, Apr 9, 2020 at 7:49 PM Xiang Xiao wrote: > This build error happen for several special config only, and already exist > > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: > > > > Xiang, > > > > Do the parallel build failures block our release? If so, what can we do > > Shouldn't, because: > 1.The build error already exist for a long time > 2.Only several seldom used configs(all related to binfmt/module/so) > hit this issue > 3.The single thread build can always finish successfully > > > temporarily to unblock it? Or is there a fix in the works that will be > > ready soon? > > > > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent > month, some issue get fixed, but some need more time to investigate. > > > -adam > > > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao > wrote: > > > > > At least, the parallel build still fail randomly which block our > > > nightly checker. > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
This build error happen for several special config only, and already exist On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer wrote: > > Xiang, > > Do the parallel build failures block our release? If so, what can we do Shouldn't, because: 1.The build error already exist for a long time 2.Only several seldom used configs(all related to binfmt/module/so) hit this issue 3.The single thread build can always finish successfully > temporarily to unblock it? Or is there a fix in the works that will be > ready soon? > Masayuki, Haitao, Yamamoto and I try to fix the problem in the recent month, some issue get fixed, but some need more time to investigate. > -adam > > On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao wrote: > > > At least, the parallel build still fail randomly which block our > > nightly checker.
Re: Start of the NuttX 9.0 release cycle
Xiang, Do the parallel build failures block our release? If so, what can we do temporarily to unblock it? Or is there a fix in the works that will be ready soon? -adam On Thu, Apr 9, 2020 at 7:29 PM Xiang Xiao wrote: > At least, the parallel build still fail randomly which block our > nightly checker.
Re: Start of the NuttX 9.0 release cycle
On Thu, Apr 9, 2020 at 3:28 PM Adam Feuer wrote: > Abdelatif and Nathan, > > Let's get the release notes wiki page the way we want it, then put it in a > PR for the release notes file. > > -adam Yes that's a sensible plan. Nathan
Re: Start of the NuttX 9.0 release cycle
At least, the parallel build still fail randomly which block our nightly checker. On Fri, Apr 10, 2020 at 10:07 AM Brennan Ashton wrote: > > Beyond the release notes do we have any outstanding bugs or other tasks > that need to be addressed? > > I gave the license and notice files a update with what I had from Fossology > (minus the BSD changes that we will need to work on going forward) > > --Brennan > > > On Thu, Apr 9, 2020, 12:28 PM Adam Feuer wrote: > > > Abdelatif and Nathan, > > > > Let's get the release notes wiki page the way we want it, then put it in a > > PR for the release notes file. > > > > -adam > > > > On Thu, Apr 9, 2020 at 11:56 AM Abdelatif Guettouche < > > abdelatif.guettou...@gmail.com> wrote: > > > > > Hi, > > > > > > Since the release branch got created there have been some bugfixes, > > > improvements and one new board. I suggest we rebase the branch and > > > get everything in. > > > However for the rest, we only cherry pick what's necessary for the > > release. > > > Speaking about the branch, Brennan is suggesting to have a different > > > naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the > > > reasons behind this are here: > > > https://github.com/apache/incubator-nuttx/pull/757) > > > > > > For the release notes, as mentioned in the other thread, I opened a > > > draft PR, maybe Adam and Nathan would like to push there or do the > > > same and open a separate PR. > > > > > > On Wed, Apr 8, 2020 at 3:08 AM Nathan Hartman > > > wrote: > > > > > > > > On Tue, Apr 7, 2020 at 9:02 PM Gregory Nutt > > wrote: > > > > > That spreadsheet is the old release steps that I did. Its content > > > > > should probably should be retained as is since it is history. > > > > > > > > I can appreciate that. > > > > > > > > Thanks, > > > > Nathan > > > > > > > > > -- > > Adam Feuer > >
Re: Start of the NuttX 9.0 release cycle
Beyond the release notes do we have any outstanding bugs or other tasks that need to be addressed? I gave the license and notice files a update with what I had from Fossology (minus the BSD changes that we will need to work on going forward) --Brennan On Thu, Apr 9, 2020, 12:28 PM Adam Feuer wrote: > Abdelatif and Nathan, > > Let's get the release notes wiki page the way we want it, then put it in a > PR for the release notes file. > > -adam > > On Thu, Apr 9, 2020 at 11:56 AM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > Hi, > > > > Since the release branch got created there have been some bugfixes, > > improvements and one new board. I suggest we rebase the branch and > > get everything in. > > However for the rest, we only cherry pick what's necessary for the > release. > > Speaking about the branch, Brennan is suggesting to have a different > > naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the > > reasons behind this are here: > > https://github.com/apache/incubator-nuttx/pull/757) > > > > For the release notes, as mentioned in the other thread, I opened a > > draft PR, maybe Adam and Nathan would like to push there or do the > > same and open a separate PR. > > > > On Wed, Apr 8, 2020 at 3:08 AM Nathan Hartman > > wrote: > > > > > > On Tue, Apr 7, 2020 at 9:02 PM Gregory Nutt > wrote: > > > > That spreadsheet is the old release steps that I did. Its content > > > > should probably should be retained as is since it is history. > > > > > > I can appreciate that. > > > > > > Thanks, > > > Nathan > > > > > -- > Adam Feuer >
Re: Start of the NuttX 9.0 release cycle
Abdelatif and Nathan, Let's get the release notes wiki page the way we want it, then put it in a PR for the release notes file. -adam On Thu, Apr 9, 2020 at 11:56 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > Hi, > > Since the release branch got created there have been some bugfixes, > improvements and one new board. I suggest we rebase the branch and > get everything in. > However for the rest, we only cherry pick what's necessary for the release. > Speaking about the branch, Brennan is suggesting to have a different > naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the > reasons behind this are here: > https://github.com/apache/incubator-nuttx/pull/757) > > For the release notes, as mentioned in the other thread, I opened a > draft PR, maybe Adam and Nathan would like to push there or do the > same and open a separate PR. > > On Wed, Apr 8, 2020 at 3:08 AM Nathan Hartman > wrote: > > > > On Tue, Apr 7, 2020 at 9:02 PM Gregory Nutt wrote: > > > That spreadsheet is the old release steps that I did. Its content > > > should probably should be retained as is since it is history. > > > > I can appreciate that. > > > > Thanks, > > Nathan > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
Hi, Since the release branch got created there have been some bugfixes, improvements and one new board. I suggest we rebase the branch and get everything in. However for the rest, we only cherry pick what's necessary for the release. Speaking about the branch, Brennan is suggesting to have a different naming convention. Instead of nuttx-XX.YY we use releases/XX.YY (the reasons behind this are here: https://github.com/apache/incubator-nuttx/pull/757) For the release notes, as mentioned in the other thread, I opened a draft PR, maybe Adam and Nathan would like to push there or do the same and open a separate PR. On Wed, Apr 8, 2020 at 3:08 AM Nathan Hartman wrote: > > On Tue, Apr 7, 2020 at 9:02 PM Gregory Nutt wrote: > > That spreadsheet is the old release steps that I did. Its content > > should probably should be retained as is since it is history. > > I can appreciate that. > > Thanks, > Nathan
Re: Start of the NuttX 9.0 release cycle
On Tue, Apr 7, 2020 at 9:02 PM Gregory Nutt wrote: > That spreadsheet is the old release steps that I did. Its content > should probably should be retained as is since it is history. I can appreciate that. Thanks, Nathan
Re: Start of the NuttX 9.0 release cycle
I wonder if there's a reason it has to be a spreadsheet? You are welcome to do anything that you would like with the file. Thanks. I haven't actually seen the file but we'll try to figure out as a community what's the best way to document, or better yet, automate as many steps as possible, to reduce effort and potential for mistakes. That spreadsheet is the old release steps that I did. Its content should probably should be retained as is since it is history. Although you can change the presentation format if you like. I would not consider modifying this for the 9.0 release. Rather, is should help to provide some inputs to the 9.0 checklist at https://cwiki.apache.org/confluence/display/NUTTX/Release+9.0+Checklist
Re: Start of the NuttX 9.0 release cycle
On Tue, Apr 7, 2020 at 8:02 PM Gregory Nutt wrote: > > > I wonder if there's a reason it has to be a spreadsheet? > You are welcome to do anything that you would like with the file. > Thanks. I haven't actually seen the file but we'll try to figure out as a community what's the best way to document, or better yet, automate as many steps as possible, to reduce effort and potential for mistakes. Cheers, Nathan
Re: Start of the NuttX 9.0 release cycle
I wonder if there's a reason it has to be a spreadsheet? You are welcome to do anything that you would like with the file.
Re: Start of the NuttX 9.0 release cycle
On Tue, Apr 7, 2020 at 5:49 PM Adam Feuer wrote: > https://cwiki.apache.org/confluence/display/NUTTX/Project+Administration > > If you click Edit > + > Files and Images, I think you can do it that way. I wonder if there's a reason it has to be a spreadsheet? Nathan
Re: Start of the NuttX 9.0 release cycle
Re: sharing spreadsheets, how about attaching it to a wiki page, maybe here? https://cwiki.apache.org/confluence/display/NUTTX/Project+Administration If you click Edit > + > Files and Images, I think you can do it that way. -adam On Tue, Apr 7, 2020 at 12:49 PM Gregory Nutt wrote: > > > Perhaps we could get Greg's input, as far as steps did you take when > > making tarballs for earlier releases? It will, of course, be important > > that we document what we do as well as possible. > > Yes, I have a check list. it is a spreadsheet, so I cannot attach it > for distribution. I gave a copy to Abdelatif and walked him throuh most > of the steps. But I don't know how to share anything here do to the > severe limitations of d...@nuttx.aparche.org. > > > > -- Adam Feuer
Re: Start of the NuttX 9.0 release cycle
On Tue, Apr 7, 2020, 12:15 PM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > At this time, we will need nuttx-9.0-incubating-rc1 (and, possibly, > > nuttx-apps-9.0-incubating-rc1) tarballs. > > > Shouldn't we do some work on this first; like release notes and updating > all the files that need to be updated. > When we create the tarballs we are going to put the RC for a vote in our > dev@ list. It needs to be in shape to pass the vote. > > Perhaps we could get Greg's input, as far as steps did you take when > > making tarballs for earlier releases? > > > He used to use the zipme.sh script. I added few things to the script today > so we can use it for Apache releases. > (https://github.com/apache/incubator-nuttx/pull/748) > I know that we cannot use CI artifacts for the releases (I don't quite understand the logic but it seems to be policy), but I can wire this script into the CI so that we create the artifacts from the builds and help document this process kind of like we have with the docs build step. This is something I can do tonight. Also once we have a release ready for the website I am happy to link it like I did with the old release and update the docs from the build into the wiki. --Brennan >
Re: Start of the NuttX 9.0 release cycle
Perhaps we could get Greg's input, as far as steps did you take when making tarballs for earlier releases? It will, of course, be important that we document what we do as well as possible. Yes, I have a check list. it is a spreadsheet, so I cannot attach it for distribution. I gave a copy to Abdelatif and walked him throuh most of the steps. But I don't know how to share anything here do to the severe limitations of d...@nuttx.aparche.org.
Re: Start of the NuttX 9.0 release cycle
> > Do we intend to also make an apps-9.0 branch for the > incubator-nuttx-apps repository? > Yes, we'll add that one as well. I'm thinking about rebasing the nuttx-9.0 branch since we still haven't backported anything to it yet. What do you think? At this time, we will need nuttx-9.0-incubating-rc1 (and, possibly, > nuttx-apps-9.0-incubating-rc1) tarballs. > Shouldn't we do some work on this first; like release notes and updating all the files that need to be updated. When we create the tarballs we are going to put the RC for a vote in our dev@ list. It needs to be in shape to pass the vote. Perhaps we could get Greg's input, as far as steps did you take when > making tarballs for earlier releases? > He used to use the zipme.sh script. I added few things to the script today so we can use it for Apache releases. (https://github.com/apache/incubator-nuttx/pull/748) On Tue, Apr 7, 2020 at 8:03 PM Nathan Hartman wrote: > On Mon, Apr 6, 2020 at 10:16 AM Abdelatif Guettouche > wrote: > > As discussed in the previous thread [1], today is the start of the > > NuttX 9.0 release cycle. The release process is outlined in the link > > below. > > This is another chance for others to express their opinions, > > suggestions or concerns. > > > > Otherwise, we will move forward with the proposed release process. > > So today we create the nuttx-9.0 branch and start the first release > candidate. > > > > [1]. > https://lists.apache.org/thread.html/ref65dd30876e134cd4f86dd83668370bf414138b9adcf618292cd779%40%3Cdev.nuttx.apache.org%3E > > Hi all, > > First of all, thanks to everyone for helping this great project make > this important milestone! > > The nuttx-9.0 branch has been created. > > Do we intend to also make an apps-9.0 branch for the > incubator-nuttx-apps repository? > > At this time, we will need nuttx-9.0-incubating-rc1 (and, possibly, > nuttx-apps-9.0-incubating-rc1) tarballs. > > Perhaps we could get Greg's input, as far as steps did you take when > making tarballs for earlier releases? It will, of course, be important > that we document what we do as well as possible. > > For completeness, here's a link to the 9.0 Release Checklist on Confluence: > https://cwiki.apache.org/confluence/display/NUTTX/Release+9.0+Checklist > > Nathan >
Re: Start of the NuttX 9.0 release cycle
Nice! Op di 7 apr. 2020 om 21:03 schreef Nathan Hartman : > On Mon, Apr 6, 2020 at 10:16 AM Abdelatif Guettouche > wrote: > > As discussed in the previous thread [1], today is the start of the > > NuttX 9.0 release cycle. The release process is outlined in the link > > below. > > This is another chance for others to express their opinions, > > suggestions or concerns. > > > > Otherwise, we will move forward with the proposed release process. > > So today we create the nuttx-9.0 branch and start the first release > candidate. > > > > [1]. > https://lists.apache.org/thread.html/ref65dd30876e134cd4f86dd83668370bf414138b9adcf618292cd779%40%3Cdev.nuttx.apache.org%3E > > Hi all, > > First of all, thanks to everyone for helping this great project make > this important milestone! > > The nuttx-9.0 branch has been created. > > Do we intend to also make an apps-9.0 branch for the > incubator-nuttx-apps repository? > > At this time, we will need nuttx-9.0-incubating-rc1 (and, possibly, > nuttx-apps-9.0-incubating-rc1) tarballs. > > Perhaps we could get Greg's input, as far as steps did you take when > making tarballs for earlier releases? It will, of course, be important > that we document what we do as well as possible. > > For completeness, here's a link to the 9.0 Release Checklist on Confluence: > https://cwiki.apache.org/confluence/display/NUTTX/Release+9.0+Checklist > > Nathan >
Re: Start of the NuttX 9.0 release cycle
On Mon, Apr 6, 2020 at 10:16 AM Abdelatif Guettouche wrote: > As discussed in the previous thread [1], today is the start of the > NuttX 9.0 release cycle. The release process is outlined in the link > below. > This is another chance for others to express their opinions, > suggestions or concerns. > > Otherwise, we will move forward with the proposed release process. > So today we create the nuttx-9.0 branch and start the first release candidate. > > [1]. > https://lists.apache.org/thread.html/ref65dd30876e134cd4f86dd83668370bf414138b9adcf618292cd779%40%3Cdev.nuttx.apache.org%3E Hi all, First of all, thanks to everyone for helping this great project make this important milestone! The nuttx-9.0 branch has been created. Do we intend to also make an apps-9.0 branch for the incubator-nuttx-apps repository? At this time, we will need nuttx-9.0-incubating-rc1 (and, possibly, nuttx-apps-9.0-incubating-rc1) tarballs. Perhaps we could get Greg's input, as far as steps did you take when making tarballs for earlier releases? It will, of course, be important that we document what we do as well as possible. For completeness, here's a link to the 9.0 Release Checklist on Confluence: https://cwiki.apache.org/confluence/display/NUTTX/Release+9.0+Checklist Nathan
Start of the NuttX 9.0 release cycle
Hi, As discussed in the previous thread [1], today is the start of the NuttX 9.0 release cycle. The release process is outlined in the link below. This is another chance for others to express their opinions, suggestions or concerns. Otherwise, we will move forward with the proposed release process. So today we create the nuttx-9.0 branch and start the first release candidate. [1]. https://lists.apache.org/thread.html/ref65dd30876e134cd4f86dd83668370bf414138b9adcf618292cd779%40%3Cdev.nuttx.apache.org%3E
