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 <a...@starcat.io> 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 <abdelatif.guettou...@gmail.com> 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 <a...@starcat.io> 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 <xiaoxiang781...@gmail.com> >> >> wrote: >> >> >> >> > This build error happen for several special config only, and already >> >> > exist >> >> > >> >> > On Fri, Apr 10, 2020 at 10:38 AM Adam Feuer <a...@starcat.io> 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 <a...@starcat.io> >> > >> > > > -- > Adam Feuer <a...@starcat.io> > -- Adam Feuer <a...@starcat.io>
