> -Original Message-
> From: Abdelatif Guettouche
> Sent: Saturday, May 23, 2020 9:18 PM
> To: dev@nuttx.apache.org
> Subject: Re: Release Notes for the NEXT version of NuttX
>
> > Yes, it's better to accumulative all patch for a specific release candidate
t, May 23, 2020 at 7:40 AM Xiang Xiao wrote:
>
>
>
> > -Original Message-
> > From: Nathan Hartman
> > Sent: Saturday, May 23, 2020 5:11 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Release Notes for the NEXT version of NuttX
> >
> >
> -Original Message-
> From: Nathan Hartman
> Sent: Saturday, May 23, 2020 5:11 AM
> To: dev@nuttx.apache.org
> Subject: Re: Release Notes for the NEXT version of NuttX
>
> On Fri, May 22, 2020 at 4:54 PM Brennan Ashton
> wrote:
> > Neverm
> You want to find the point at which it was branched, something like
>
> git log master..releasebranch --oneline | tail -1
That actually gives the first commit that's not in master, we'd be
interested in its parent
"git log master..releases/9.0 --oneline --format='%p' | tail -1"
On Fri, May
Why are we interested in individual commits? PRs bundle all the changes
and are easier to retrieve.
In any case, we can filter out cherry picked commits with something like
"git log --oneline --cherry-pick --right-only releases/9.0...master"
On Fri, May 22, 2020 at 10:37 PM Nathan Hartman
On Fri, May 22, 2020 at 5:12 PM Gregory Nutt wrote:
> This is what I used to do for the old releases (from 8.2
> tools/README.txt, from show 6168f3ebf046e4c3d5561bfa96a39d0f02b771db):
snip
> -logparser.c
>
> -
> - Convert a git log to ChangeLog format. Recommended usage:
> -
> -
This is what I used to do for the old releases (from 8.2
tools/README.txt, from show 6168f3ebf046e4c3d5561bfa96a39d0f02b771db):
index 42c71fd52d..64666eb550 100644
--- a/tools/README.txt
+++ b/tools/README.txt
@@ -745,15 +745,6 @@ link.sh, link.bat, copydir.sh, copydir.bat,
unlink.sh, and
On Fri, May 22, 2020 at 4:54 PM Brennan Ashton
wrote:
> Nevermind I see what you were asking for. There is no great way to do this
> with git directly, usually you track this by using labels (or similar) on
> issues or PRs to aggregate it. At least that is that is how I have always
> run releases
On Fri, May 22, 2020, 1:49 PM Brennan Ashton
wrote:
> You want to find the point at which it was branched, something like
>
> git log master..releasebranch --oneline | tail -1
>
> Then you can use it for the base of log
>
> git log branched-commit..master
>
>
Nevermind I see what you were
You want to find the point at which it was branched, something like
git log master..releasebranch --oneline | tail -1
Then you can use it for the base of log
git log branched-commit..master
--Brennan
On Fri, May 22, 2020, 1:30 PM Nathan Hartman
wrote:
> In preparation for the 9.1 release
In preparation for the 9.1 release notes...
What git incantation will get the log, excluding all commits present
in the 9.0 release?
Specifically, I want to include commits after 9.0 was branched, but
exclude commits that were cherry-picked to 9.0.
Thanks,
Nathan
On Thu, May 14, 2020 at 11:07 PM Abdelatif Guettouche
wrote:
>
> That looks good.
> Just one small thing: Is your board in-tree with other STM32s?
> I'm asking because the referenced commit didn't make the change to the
> build system, it re-organized the STM32 boards. The "real" change to
> the
That looks good.
Just one small thing: Is your board in-tree with other STM32s?
I'm asking because the referenced commit didn't make the change to the
build system, it re-organized the STM32 boards. The "real" change to
the build system was made in a previous release (8.2?) when Alin and
Greg
On Thu, May 14, 2020 at 6:40 PM Abdelatif Guettouche
wrote:
> I noted one thing:
> "Rename src/Makefile to src/Make.defs"
> I'm not sure about this one, this applies only if the board family
> uses a common directory (like CXD56 does and recently STM32).
> The "Makefile" way still works and is
Thank you for this initiative, this will make preparing release notes
much easier.
I noted one thing:
"Rename src/Makefile to src/Make.defs"
I'm not sure about this one, this applies only if the board family
uses a common directory (like CXD56 does and recently STM32).
The "Makefile" way still
After the release of NuttX-9.0, there have been some build system
changes that starting with NuttX-9.1 will likely break custom board
configurations that people might have.
While the information is fresh in my head, I went ahead and created on
Confluence a page to start working on our next
16 matches
Mail list logo
