Creating 9.1.0-RC0

[Brennan Ashton <ba...@brennanashton.com>]

Hey all,
So according to the plan from a couple weeks ago, tomorrow the 22th we
are going to be cutting the 9.1.0-R0 release and putting it up for a
vote.  In the last couple weeks there has been a lot of moving bits on
master and we have not backported anything to the 9.1 branch.  I have
done some testing on the ports I have an interest in, but I do not
have a good sense of any other testing that has happened.

My plan  is to create the RC tomorrow evening Pacific Time.  We also
need to take the release notes from the wiki and move them to git.  If
someone wants to take on that task feel free to speak up.  Also if
there are any fixes that should be backported, shifting the release by
a day or two is not a big deal, I would rather do that then have to go
through another fix release cycle.

--Brennan

Re: Creating 9.1.0-RC0

[Brennan Ashton <ba...@brennanashton.com>]

On Mon, Jun 22, 2020, 4:01 AM Abdelatif Guettouche <
abdelatif.guettouche@gmail.com> wrote:

> Hi,
>
> I took care of the remaining PRs in the Projects' backlog.  Only the
> CI one is still there, we don't have any entry for CI related changes
> in our release note template, I think we should add one.
>
> With regards to bringing the release notes to the repo, that needs to
> go to master then backported to the release branch.  Are we all on the
> same page with this?
> We also need to update a couple of documentation files to add any new
> board, chip or architecture.
>

I intentionally left out all of the CI changes from the release as I did
not think they were that important to end users of it an the notes are
already really long. Maybe we can revisit that for the next release?

But other than that yes I think we are on the same page.

--Brennan

>

Re: Creating 9.1.0-RC0

[Abdelatif Guettouche <ab...@gmail.com>]

> Hmmm... I believe that the whole point of Release Notes is to point
> out things like Compatibility Concerns that our downstream users and
> developers will want to know about before they attempt to update and
> learn the hard way that their code doesn't build or doesn't run
> correctly. But that's just my opinion. Let's see what others think.

I agree that it's important to highlight compatibility concerns and
guide downstream users, it just didn't fit in that file.  Sorry I
wasn't too clear, it was a suggestion and I should have mentioned that
anyone could push to the PR and change it if need be.

> Perhaps we could consider an alternate solution: Instead of one huge
> ReleaseNotes file that will only continue growing without bounds,
> perhaps the ReleaseNotes file should document the latest release only,
> and all prior release notes could be moved to separate files in a
> subdirectory? Each time we make a release, move ReleaseNotes into that
> subdirectory (and rename it, e.g., ReleaseNotes-9.1) and create a new
> ReleaseNotes file in its place?

It has been suggested before to keep only the latest release notes in
the top level file. The downside was that we didn't want users to
juggle with GIT to retrieve earlier release notes.  Having a subdir
with the old release notes could actually solve both issues.
Another point is the template format.  What are your thoughts on using
Markdown?  Both in the Wiki and in ReleaseNote.
Using it in the Wiki will ease copy pasting without being concerned
about formatting (Thanks Brennan for fixing the PR!) and in the
ReleaseNote we will still have a readable text file but also one that
can be auto formatted by any Markdown-aware tool/website.


On Tue, Jun 23, 2020 at 4:36 AM Nathan Hartman <ha...@gmail.com> wrote:
>
> On Mon, Jun 22, 2020 at 10:13 PM Brennan Ashton <ba...@brennanashton.com>
> wrote:
>
> > On Mon, Jun 22, 2020, 5:38 PM Nathan Hartman <ha...@gmail.com>
> > wrote:
> >
> > > On Mon, Jun 22, 2020 at 4:46 PM Abdelatif Guettouche
> > > <ab...@gmail.com> wrote:
> > > > I created a PR copying the release notes from Confluence to ReleaseNote
> > > file.
> > > > I did not copy the "Compatibility Concerns" part, that's valuable
> > > > information but I don't think it belongs to that file, just because
> > > > there is a lot of explanation and code snippets which are not well
> > > > suited for the template of that file.
> > > > Speaking of which, I believe we should reconsider the ReleaseNote file
> > > > and its content.  It's hard to navigate a 27K+ file.   That's a
> > > > discussion for another thread, just put it here as a reminder for
> > > > myself.
> > >
> > > Hmmm... I believe that the whole point of Release Notes is to point
> > > out things like Compatibility Concerns that our downstream users and
> > > developers will want to know about before they attempt to update and
> > > learn the hard way that their code doesn't build or doesn't run
> > > correctly. But that's just my opinion. Let's see what others think.
> > >
> >
> > Nathan,
> > Do you want to make any of these changes for this release? I would like to
> > bring the Release Notes in the to release branch to cut a release in the
> > next few hours.
> >
> > I agree that we should probably have some discussion about release notes
> > and documentation going forward.
>
>
>
> I think it's best to proceed with the release candidate as-is.
>
> I agree with Abdelatif that the release notes file is beginning to grow too
> large to add so much new information to it, so I think that we should as a
> community discuss how to deal with this moving forward. For now, the
> information is  documented at the wiki.
>
> Thanks,
> Nathan

Re: Creating 9.1.0-RC0

[Nathan Hartman <ha...@gmail.com>]

On Mon, Jun 22, 2020 at 10:13 PM Brennan Ashton <ba...@brennanashton.com>
wrote:

> On Mon, Jun 22, 2020, 5:38 PM Nathan Hartman <ha...@gmail.com>
> wrote:
>
> > On Mon, Jun 22, 2020 at 4:46 PM Abdelatif Guettouche
> > <ab...@gmail.com> wrote:
> > > I created a PR copying the release notes from Confluence to ReleaseNote
> > file.
> > > I did not copy the "Compatibility Concerns" part, that's valuable
> > > information but I don't think it belongs to that file, just because
> > > there is a lot of explanation and code snippets which are not well
> > > suited for the template of that file.
> > > Speaking of which, I believe we should reconsider the ReleaseNote file
> > > and its content.  It's hard to navigate a 27K+ file.   That's a
> > > discussion for another thread, just put it here as a reminder for
> > > myself.
> >
> > Hmmm... I believe that the whole point of Release Notes is to point
> > out things like Compatibility Concerns that our downstream users and
> > developers will want to know about before they attempt to update and
> > learn the hard way that their code doesn't build or doesn't run
> > correctly. But that's just my opinion. Let's see what others think.
> >
>
> Nathan,
> Do you want to make any of these changes for this release? I would like to
> bring the Release Notes in the to release branch to cut a release in the
> next few hours.
>
> I agree that we should probably have some discussion about release notes
> and documentation going forward.



I think it's best to proceed with the release candidate as-is.

I agree with Abdelatif that the release notes file is beginning to grow too
large to add so much new information to it, so I think that we should as a
community discuss how to deal with this moving forward. For now, the
information is  documented at the wiki.

Thanks,
Nathan

Re: Creating 9.1.0-RC0

[Brennan Ashton <ba...@brennanashton.com>]

On Mon, Jun 22, 2020, 5:38 PM Nathan Hartman <ha...@gmail.com>
wrote:

> On Mon, Jun 22, 2020 at 4:46 PM Abdelatif Guettouche
> <ab...@gmail.com> wrote:
> > I created a PR copying the release notes from Confluence to ReleaseNote
> file.
> > I did not copy the "Compatibility Concerns" part, that's valuable
> > information but I don't think it belongs to that file, just because
> > there is a lot of explanation and code snippets which are not well
> > suited for the template of that file.
> > Speaking of which, I believe we should reconsider the ReleaseNote file
> > and its content.  It's hard to navigate a 27K+ file.   That's a
> > discussion for another thread, just put it here as a reminder for
> > myself.
>
> Hmmm... I believe that the whole point of Release Notes is to point
> out things like Compatibility Concerns that our downstream users and
> developers will want to know about before they attempt to update and
> learn the hard way that their code doesn't build or doesn't run
> correctly. But that's just my opinion. Let's see what others think.
>

Nathan,
Do you want to make any of these changes for this release? I would like to
bring the Release Notes in the to release branch to cut a release in the
next few hours.

I agree that we should probably have some discussion about release notes
and documentation going forward.

--Brennan

>

Re: Creating 9.1.0-RC0

[Nathan Hartman <ha...@gmail.com>]

On Mon, Jun 22, 2020 at 4:46 PM Abdelatif Guettouche
<ab...@gmail.com> wrote:
> I created a PR copying the release notes from Confluence to ReleaseNote file.
> I did not copy the "Compatibility Concerns" part, that's valuable
> information but I don't think it belongs to that file, just because
> there is a lot of explanation and code snippets which are not well
> suited for the template of that file.
> Speaking of which, I believe we should reconsider the ReleaseNote file
> and its content.  It's hard to navigate a 27K+ file.   That's a
> discussion for another thread, just put it here as a reminder for
> myself.

Hmmm... I believe that the whole point of Release Notes is to point
out things like Compatibility Concerns that our downstream users and
developers will want to know about before they attempt to update and
learn the hard way that their code doesn't build or doesn't run
correctly. But that's just my opinion. Let's see what others think.

Perhaps we could consider an alternate solution: Instead of one huge
ReleaseNotes file that will only continue growing without bounds,
perhaps the ReleaseNotes file should document the latest release only,
and all prior release notes could be moved to separate files in a
subdirectory? Each time we make a release, move ReleaseNotes into that
subdirectory (and rename it, e.g., ReleaseNotes-9.1) and create a new
ReleaseNotes file in its place?

Thoughts?

Nathan

Re: Creating 9.1.0-RC0

[Abdelatif Guettouche <ab...@gmail.com>]

I created a PR copying the release notes from Confluence to ReleaseNote file.
I did not copy the "Compatibility Concerns" part, that's valuable
information but I don't think it belongs to that file, just because
there is a lot of explanation and code snippets which are not well
suited for the template of that file.
Speaking of which, I believe we should reconsider the ReleaseNote file
and its content.  It's hard to navigate a 27K+ file.   That's a
discussion for another thread, just put it here as a reminder for
myself.

On Mon, Jun 22, 2020 at 3:51 PM Nathan Hartman <ha...@gmail.com> wrote:
>
> On Mon, Jun 22, 2020 at 10:35 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> >  I created PR 1277 to add that to documentation:
> > >
> > > https://github.com/apache/incubator-nuttx/pull/1277
> > The Confluence landing page needs to be updated too (usually not more
> > than  half dozen words).
> >
>
> Done. Thanks for the reminder.
>
> Nathan

Re: Creating 9.1.0-RC0

[Nathan Hartman <ha...@gmail.com>]

On Mon, Jun 22, 2020 at 10:35 AM Gregory Nutt <sp...@gmail.com> wrote:

>  I created PR 1277 to add that to documentation:
> >
> > https://github.com/apache/incubator-nuttx/pull/1277
> The Confluence landing page needs to be updated too (usually not more
> than  half dozen words).
>

Done. Thanks for the reminder.

Nathan

Re: Creating 9.1.0-RC0

[Gregory Nutt <sp...@gmail.com>]

>> With regards to bringing the release notes to the repo, that needs to
>> go to master then backported to the release branch.  Are we all on the
>> same page with this?
>
> +1
>
> We also need to update a couple of documentation files to add any new
>> board, chip or architecture.
>
> Yes, there is the STM32G4xx MCU support and discovery board.
>
> I created PR 1277 to add that to documentation:
>
> https://github.com/apache/incubator-nuttx/pull/1277
The Confluence landing page needs to be updated too (usually not more 
than  half dozen words).

Re: Creating 9.1.0-RC0

[Nathan Hartman <ha...@gmail.com>]

On Mon, Jun 22, 2020 at 7:01 AM Abdelatif Guettouche <
abdelatif.guettouche@gmail.com> wrote:

>
> With regards to bringing the release notes to the repo, that needs to
> go to master then backported to the release branch.  Are we all on the
> same page with this?


+1

We also need to update a couple of documentation files to add any new
> board, chip or architecture.


Yes, there is the STM32G4xx MCU support and discovery board.

I created PR 1277 to add that to documentation:

https://github.com/apache/incubator-nuttx/pull/1277

Cheers,
Nathan

Re: Creating 9.1.0-RC0

[Abdelatif Guettouche <ab...@gmail.com>]

Hi,

I took care of the remaining PRs in the Projects' backlog.  Only the
CI one is still there, we don't have any entry for CI related changes
in our release note template, I think we should add one.

With regards to bringing the release notes to the repo, that needs to
go to master then backported to the release branch.  Are we all on the
same page with this?
We also need to update a couple of documentation files to add any new
board, chip or architecture.

On Mon, Jun 22, 2020 at 5:10 AM Brennan Ashton
<ba...@brennanashton.com> wrote:
>
> Hey all,
> So according to the plan from a couple weeks ago, tomorrow the 22th we
> are going to be cutting the 9.1.0-R0 release and putting it up for a
> vote.  In the last couple weeks there has been a lot of moving bits on
> master and we have not backported anything to the 9.1 branch.  I have
> done some testing on the ports I have an interest in, but I do not
> have a good sense of any other testing that has happened.
>
> My plan  is to create the RC tomorrow evening Pacific Time.  We also
> need to take the release notes from the wiki and move them to git.  If
> someone wants to take on that task feel free to speak up.  Also if
> there are any fixes that should be backported, shifting the release by
> a day or two is not a big deal, I would rather do that then have to go
> through another fix release cycle.
>
> --Brennan