Release 9.1

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

Hi, all

If we are serious about getting on a two month release cycle again, now 
is the time to begin thinking about the 9.1 release. We created the 9.0 
release branch sometime before the 15th of April.   We signed the 
release on April 23rd.  So we have some time, but also we need to start 
get some plans and organization in place.  And we need to think about 
doing everything we can to make the master stable for that branch.  We 
should hold off large, sweeping changes until we get past that point.

Duo... you mentioned that you were interested with assisted with the 
releases?  Abdelatif was the point man last time.  Perhaps you would 
want to discuss his experiences with him?

Greg

Re: Release 9.1

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

On Mon, Jun 15, 2020, 9:14 AM Abdelatif Guettouche <
abdelatif.guettouche@gmail.com> wrote:

> Thanks Nathan,
>
> > if there's anything else to add to the 9.1 release notes, that page
> > remains here:
> > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1
>
> I think there is one PR in nuttx/ that's not included in the release
> notes and maybe two in apps/.  That should be quick.
> Another thing left to do is to update the release note document in the
> repo and all the relevant files under Documentation/.
>

Abdelatif,
Thanks for creating the branches, I was not going to be able to get to it
until after work today, so it's good to unblock the queue of PRs for master.

Nathan,
I will create new tracking projects for the 9.2 this evening for the
projects. I think it will be a lot easier having this rolling from the
start of the cycle. Thanks for getting the template up.

Re: Release 9.1

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

Thanks Nathan,

> if there's anything else to add to the 9.1 release notes, that page
> remains here:
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1

I think there is one PR in nuttx/ that's not included in the release
notes and maybe two in apps/.  That should be quick.
Another thing left to do is to update the release note document in the
repo and all the relevant files under Documentation/.


On Mon, Jun 15, 2020 at 3:39 PM Nathan Hartman <ha...@gmail.com> wrote:
>
> On Mon, Jun 15, 2020 at 8:58 AM Abdelatif Guettouche
> <ab...@gmail.com> wrote:
> > Hi all,
> >
> > D-Day; I'll go ahead and create the branches.
>
> Thank you!
>
> I went ahead and created a blank release notes wiki for the *next*
> release, 9.2, here:
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.2
>
> If there's anything else to add to the 9.1 release notes, that page
> remains here:
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1
>
> Cheers,
> Nathan

Re: Release 9.1

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

On Mon, Jun 15, 2020 at 8:58 AM Abdelatif Guettouche
<ab...@gmail.com> wrote:
> Hi all,
>
> D-Day; I'll go ahead and create the branches.

Thank you!

I went ahead and created a blank release notes wiki for the *next*
release, 9.2, here:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.2

If there's anything else to add to the 9.1 release notes, that page
remains here:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1

Cheers,
Nathan

Re: Release 9.1

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

Hi all,

D-Day; I'll go ahead and create the branches.

On Tue, Jun 9, 2020 at 2:42 PM Abdelatif Guettouche
<ab...@gmail.com> wrote:
>
> > I guess the other question I want to know is what is on master that is not
> > in the release?
>
> There are some git log options that we can use to get that.  What we
> want is to just filter out the cherry-picked commits.
> I shared this command before: "git log --oneline --cherry-pick
> --right-only releases/9.0...master"
>
>
> On Tue, Jun 9, 2020 at 1:32 PM David Sidrane <Da...@nscdg.com> wrote:
> >
> > I was speaking of git tag, for convenience.
> >
> > I guess the other question I want to know is what is on master that is not
> > in the release?
> >
> > If we use git tags: One is dropped on the branch point. One is dropped on
> > the release point. The delta on master is the full set of commits that came
> > in to master while the release was happening. The delta (tag to HEAD) on the
> > release branch is the backports, That will answer the question what is on
> > master that is not in the release.
> >
> > With tags, commit message do not need to say [BACKPORT]. But if they do say
> > [BACKPORT], all that is needed it the log to know what we back ported.
> >
> > I think one giant PR is harder to work with. Many BP PR's is fine just,
> > titled or git labeled as a back port to release r.m.n would be helpful. If
> > it is in the Title it will help filter emails. Not sure if the labels are
> > helpful in an inbox but are on Github.
> >
> > Assuming master has testing, bug fix Backport PR should be merged with 0
> > delay.
> >
> >
> > David
> >
> > -----Original Message-----
> > From: Abdelatif Guettouche [mailto:abdelatif.guettouche@gmail.com]
> > Sent: Tuesday, June 09, 2020 5:02 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Release 9.1
> >
> > > I'm also not clear are we talking about git tags here or github
> > > labels? We are using git tags but that is when we cut the release on
> > > the release branch.
> >
> > I don't know why I assumed Github labels and not git tags.  I was
> > obviously talking about Github labels.  I'm not sure how David sees
> > the use of git tags in this context.
> >
> > For backporting PRs, I don't mind either solutions, but I also prefer
> > periodically adding the PRs with the backport prefix and the PR
> > number.  I guess others had some concerns with this, maybe they can
> > help us understand.
> >
> >
> > On Tue, Jun 9, 2020 at 4:06 AM Brennan Ashton <ba...@brennanashton.com>
> > wrote:
> > >
> > > On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche
> > > <ab...@gmail.com> wrote:
> > > >
> > > > > Would tags do the same thing?
> > > > > How does this work over time?
> > > > > Many PRs or keep force pushing to the PR
> > > >
> > > > For each release there will be only one PR that hosts all the
> > > > backported commits.
> > > > And yes, tags would work I guess, it's easy to filter PRs with tags on
> > > > Github.
> > > >
> > > > > How about use cherry-pick -e and add the prefix [BACKPORT] on the back
> > > > > ported commits.
> > > >
> > > > We did something similar for PRs in the last release. Is the purpose
> > > > to be able to filter out the backported commits later?
> > >
> > > I liked what we did last release with periodically adding a PR with
> > > the backported commits.  If we just keep one giant PR with the
> > > backports this will make it harder for people to test the branch.
> > > For the most part we had the backported PR numbers in the PR title
> > > which made it really easy to match up later to figure out what did not
> > > apply to the next release.  I don't really have an opinion on the
> > > matter of if we edit the commit, but I am not sure what the added
> > > value would be.
> > >
> > > I'm also not clear are we talking about git tags here or github
> > > labels? We are using git tags but that is when we cut the release on
> > > the release branch.
> > >
> > > --Brennan

Re: Release 9.1

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

> I guess the other question I want to know is what is on master that is not
> in the release?

There are some git log options that we can use to get that.  What we
want is to just filter out the cherry-picked commits.
I shared this command before: "git log --oneline --cherry-pick
--right-only releases/9.0...master"


On Tue, Jun 9, 2020 at 1:32 PM David Sidrane <Da...@nscdg.com> wrote:
>
> I was speaking of git tag, for convenience.
>
> I guess the other question I want to know is what is on master that is not
> in the release?
>
> If we use git tags: One is dropped on the branch point. One is dropped on
> the release point. The delta on master is the full set of commits that came
> in to master while the release was happening. The delta (tag to HEAD) on the
> release branch is the backports, That will answer the question what is on
> master that is not in the release.
>
> With tags, commit message do not need to say [BACKPORT]. But if they do say
> [BACKPORT], all that is needed it the log to know what we back ported.
>
> I think one giant PR is harder to work with. Many BP PR's is fine just,
> titled or git labeled as a back port to release r.m.n would be helpful. If
> it is in the Title it will help filter emails. Not sure if the labels are
> helpful in an inbox but are on Github.
>
> Assuming master has testing, bug fix Backport PR should be merged with 0
> delay.
>
>
> David
>
> -----Original Message-----
> From: Abdelatif Guettouche [mailto:abdelatif.guettouche@gmail.com]
> Sent: Tuesday, June 09, 2020 5:02 AM
> To: dev@nuttx.apache.org
> Subject: Re: Release 9.1
>
> > I'm also not clear are we talking about git tags here or github
> > labels? We are using git tags but that is when we cut the release on
> > the release branch.
>
> I don't know why I assumed Github labels and not git tags.  I was
> obviously talking about Github labels.  I'm not sure how David sees
> the use of git tags in this context.
>
> For backporting PRs, I don't mind either solutions, but I also prefer
> periodically adding the PRs with the backport prefix and the PR
> number.  I guess others had some concerns with this, maybe they can
> help us understand.
>
>
> On Tue, Jun 9, 2020 at 4:06 AM Brennan Ashton <ba...@brennanashton.com>
> wrote:
> >
> > On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche
> > <ab...@gmail.com> wrote:
> > >
> > > > Would tags do the same thing?
> > > > How does this work over time?
> > > > Many PRs or keep force pushing to the PR
> > >
> > > For each release there will be only one PR that hosts all the
> > > backported commits.
> > > And yes, tags would work I guess, it's easy to filter PRs with tags on
> > > Github.
> > >
> > > > How about use cherry-pick -e and add the prefix [BACKPORT] on the back
> > > > ported commits.
> > >
> > > We did something similar for PRs in the last release. Is the purpose
> > > to be able to filter out the backported commits later?
> >
> > I liked what we did last release with periodically adding a PR with
> > the backported commits.  If we just keep one giant PR with the
> > backports this will make it harder for people to test the branch.
> > For the most part we had the backported PR numbers in the PR title
> > which made it really easy to match up later to figure out what did not
> > apply to the next release.  I don't really have an opinion on the
> > matter of if we edit the commit, but I am not sure what the added
> > value would be.
> >
> > I'm also not clear are we talking about git tags here or github
> > labels? We are using git tags but that is when we cut the release on
> > the release branch.
> >
> > --Brennan

RE: Release 9.1

[David Sidrane <Da...@nscdg.com>]

I was speaking of git tag, for convenience.

I guess the other question I want to know is what is on master that is not
in the release?

If we use git tags: One is dropped on the branch point. One is dropped on
the release point. The delta on master is the full set of commits that came
in to master while the release was happening. The delta (tag to HEAD) on the
release branch is the backports, That will answer the question what is on
master that is not in the release.

With tags, commit message do not need to say [BACKPORT]. But if they do say
[BACKPORT], all that is needed it the log to know what we back ported.

I think one giant PR is harder to work with. Many BP PR's is fine just,
titled or git labeled as a back port to release r.m.n would be helpful. If
it is in the Title it will help filter emails. Not sure if the labels are
helpful in an inbox but are on Github.

Assuming master has testing, bug fix Backport PR should be merged with 0
delay.


David

-----Original Message-----
From: Abdelatif Guettouche [mailto:abdelatif.guettouche@gmail.com]
Sent: Tuesday, June 09, 2020 5:02 AM
To: dev@nuttx.apache.org
Subject: Re: Release 9.1

> I'm also not clear are we talking about git tags here or github
> labels? We are using git tags but that is when we cut the release on
> the release branch.

I don't know why I assumed Github labels and not git tags.  I was
obviously talking about Github labels.  I'm not sure how David sees
the use of git tags in this context.

For backporting PRs, I don't mind either solutions, but I also prefer
periodically adding the PRs with the backport prefix and the PR
number.  I guess others had some concerns with this, maybe they can
help us understand.


On Tue, Jun 9, 2020 at 4:06 AM Brennan Ashton <ba...@brennanashton.com>
wrote:
>
> On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche
> <ab...@gmail.com> wrote:
> >
> > > Would tags do the same thing?
> > > How does this work over time?
> > > Many PRs or keep force pushing to the PR
> >
> > For each release there will be only one PR that hosts all the
> > backported commits.
> > And yes, tags would work I guess, it's easy to filter PRs with tags on
> > Github.
> >
> > > How about use cherry-pick -e and add the prefix [BACKPORT] on the back
> > > ported commits.
> >
> > We did something similar for PRs in the last release. Is the purpose
> > to be able to filter out the backported commits later?
>
> I liked what we did last release with periodically adding a PR with
> the backported commits.  If we just keep one giant PR with the
> backports this will make it harder for people to test the branch.
> For the most part we had the backported PR numbers in the PR title
> which made it really easy to match up later to figure out what did not
> apply to the next release.  I don't really have an opinion on the
> matter of if we edit the commit, but I am not sure what the added
> value would be.
>
> I'm also not clear are we talking about git tags here or github
> labels? We are using git tags but that is when we cut the release on
> the release branch.
>
> --Brennan

Re: Release 9.1

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

> I'm also not clear are we talking about git tags here or github
> labels? We are using git tags but that is when we cut the release on
> the release branch.

I don't know why I assumed Github labels and not git tags.  I was
obviously talking about Github labels.  I'm not sure how David sees
the use of git tags in this context.

For backporting PRs, I don't mind either solutions, but I also prefer
periodically adding the PRs with the backport prefix and the PR
number.  I guess others had some concerns with this, maybe they can
help us understand.


On Tue, Jun 9, 2020 at 4:06 AM Brennan Ashton <ba...@brennanashton.com> wrote:
>
> On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche
> <ab...@gmail.com> wrote:
> >
> > > Would tags do the same thing?
> > > How does this work over time?
> > > Many PRs or keep force pushing to the PR
> >
> > For each release there will be only one PR that hosts all the
> > backported commits.
> > And yes, tags would work I guess, it's easy to filter PRs with tags on Github.
> >
> > > How about use cherry-pick -e and add the prefix [BACKPORT] on the back
> > > ported commits.
> >
> > We did something similar for PRs in the last release. Is the purpose
> > to be able to filter out the backported commits later?
>
> I liked what we did last release with periodically adding a PR with
> the backported commits.  If we just keep one giant PR with the
> backports this will make it harder for people to test the branch.
> For the most part we had the backported PR numbers in the PR title
> which made it really easy to match up later to figure out what did not
> apply to the next release.  I don't really have an opinion on the
> matter of if we edit the commit, but I am not sure what the added
> value would be.
>
> I'm also not clear are we talking about git tags here or github
> labels? We are using git tags but that is when we cut the release on
> the release branch.
>
> --Brennan

Re: Release 9.1

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

On Mon, Jun 8, 2020 at 6:21 AM Abdelatif Guettouche
<ab...@gmail.com> wrote:
>
> > Would tags do the same thing?
> > How does this work over time?
> > Many PRs or keep force pushing to the PR
>
> For each release there will be only one PR that hosts all the
> backported commits.
> And yes, tags would work I guess, it's easy to filter PRs with tags on Github.
>
> > How about use cherry-pick -e and add the prefix [BACKPORT] on the back
> > ported commits.
>
> We did something similar for PRs in the last release. Is the purpose
> to be able to filter out the backported commits later?

I liked what we did last release with periodically adding a PR with
the backported commits.  If we just keep one giant PR with the
backports this will make it harder for people to test the branch.
For the most part we had the backported PR numbers in the PR title
which made it really easy to match up later to figure out what did not
apply to the next release.  I don't really have an opinion on the
matter of if we edit the commit, but I am not sure what the added
value would be.

I'm also not clear are we talking about git tags here or github
labels? We are using git tags but that is when we cut the release on
the release branch.

--Brennan

Re: Release 9.1

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

> Would tags do the same thing?
> How does this work over time?
> Many PRs or keep force pushing to the PR

For each release there will be only one PR that hosts all the
backported commits.
And yes, tags would work I guess, it's easy to filter PRs with tags on Github.

> How about use cherry-pick -e and add the prefix [BACKPORT] on the back
> ported commits.

We did something similar for PRs in the last release. Is the purpose
to be able to filter out the backported commits later?


On Mon, Jun 8, 2020 at 1:27 PM David Sidrane <Da...@nscdg.com> wrote:
>
> Would tags do the same thing?
> How does this work over time?
> Many PRs or keep force pushing to the PR?
>
> How about use cherry-pick -e and add the prefix [BACKPORT] on the back
> ported commits.
>
> -----Original Message-----
> From: Abdelatif Guettouche [mailto:abdelatif.guettouche@gmail.com]
> Sent: Monday, June 08, 2020 5:03 AM
> To: dev@nuttx.apache.org
> Subject: Re: Release 9.1
>
> Should we continue triaging PRs during the 7th-15 period?
> Then we stop and only backport what's necessary when the branch is
> created (i.e. 15th)?
>
> I also want to reiterate the backporting procedure.  Xiang was
> suggesting to create only one PR with all the commits cherry-picked.
> GIT wise we will always have the same amount of commits, but this
> could help to pinpoint where all the cherry-picked commits are and
> come in handy during the next release to separate the backported PR.
>
>
> On Mon, Jun 8, 2020 at 5:20 AM Brennan Ashton <ba...@brennanashton.com>
> wrote:
> >
> > On Wed, Jun 3, 2020 at 2:12 PM Abdelatif Guettouche
> > <ab...@gmail.com> wrote:
> > > Generating release notes is the part that has the most painful work,
> > > it took 4 of us last time to get it done.  I still wonder if there is
> > > a way to automate that, maybe with good PR summaries and consistent
> > > labeling.
> > > Nathan created a confluence page to prepare release notes for the 9.1
> > > ahead of time.
> >
> > Alright now that we at least have a draft of the release notes for
> > both the OS and Apps I would propose this timeline:
> > June 7-15th - Focus on stabilizing and any outstanding features that
> > we can close out
> > June 15th - Create the release branch 9.1 and ask for testing on that
> > branch and refine the release notes
> > June 22th - Cut RC0 and put it up for a vote to PPMC, if people are
> > feeling comfortable with the level of testing we can move this up, but
> > let's really try to get some testing in.
> > June 25th-27th - (Approximately assuming RC passes) put the RC up for
> > a vote to IPMC
> >
> > I am happy to drive this forward.
> >
> > --Brennan

RE: Release 9.1

[David Sidrane <Da...@nscdg.com>]

Would tags do the same thing?
How does this work over time?
Many PRs or keep force pushing to the PR?

How about use cherry-pick -e and add the prefix [BACKPORT] on the back
ported commits.

-----Original Message-----
From: Abdelatif Guettouche [mailto:abdelatif.guettouche@gmail.com]
Sent: Monday, June 08, 2020 5:03 AM
To: dev@nuttx.apache.org
Subject: Re: Release 9.1

Should we continue triaging PRs during the 7th-15 period?
Then we stop and only backport what's necessary when the branch is
created (i.e. 15th)?

I also want to reiterate the backporting procedure.  Xiang was
suggesting to create only one PR with all the commits cherry-picked.
GIT wise we will always have the same amount of commits, but this
could help to pinpoint where all the cherry-picked commits are and
come in handy during the next release to separate the backported PR.


On Mon, Jun 8, 2020 at 5:20 AM Brennan Ashton <ba...@brennanashton.com>
wrote:
>
> On Wed, Jun 3, 2020 at 2:12 PM Abdelatif Guettouche
> <ab...@gmail.com> wrote:
> > Generating release notes is the part that has the most painful work,
> > it took 4 of us last time to get it done.  I still wonder if there is
> > a way to automate that, maybe with good PR summaries and consistent
> > labeling.
> > Nathan created a confluence page to prepare release notes for the 9.1
> > ahead of time.
>
> Alright now that we at least have a draft of the release notes for
> both the OS and Apps I would propose this timeline:
> June 7-15th - Focus on stabilizing and any outstanding features that
> we can close out
> June 15th - Create the release branch 9.1 and ask for testing on that
> branch and refine the release notes
> June 22th - Cut RC0 and put it up for a vote to PPMC, if people are
> feeling comfortable with the level of testing we can move this up, but
> let's really try to get some testing in.
> June 25th-27th - (Approximately assuming RC passes) put the RC up for
> a vote to IPMC
>
> I am happy to drive this forward.
>
> --Brennan

Re: Release 9.1

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

Should we continue triaging PRs during the 7th-15 period?
Then we stop and only backport what's necessary when the branch is
created (i.e. 15th)?

I also want to reiterate the backporting procedure.  Xiang was
suggesting to create only one PR with all the commits cherry-picked.
GIT wise we will always have the same amount of commits, but this
could help to pinpoint where all the cherry-picked commits are and
come in handy during the next release to separate the backported PR.


On Mon, Jun 8, 2020 at 5:20 AM Brennan Ashton <ba...@brennanashton.com> wrote:
>
> On Wed, Jun 3, 2020 at 2:12 PM Abdelatif Guettouche
> <ab...@gmail.com> wrote:
> > Generating release notes is the part that has the most painful work,
> > it took 4 of us last time to get it done.  I still wonder if there is
> > a way to automate that, maybe with good PR summaries and consistent
> > labeling.
> > Nathan created a confluence page to prepare release notes for the 9.1
> > ahead of time.
>
> Alright now that we at least have a draft of the release notes for
> both the OS and Apps I would propose this timeline:
> June 7-15th - Focus on stabilizing and any outstanding features that
> we can close out
> June 15th - Create the release branch 9.1 and ask for testing on that
> branch and refine the release notes
> June 22th - Cut RC0 and put it up for a vote to PPMC, if people are
> feeling comfortable with the level of testing we can move this up, but
> let's really try to get some testing in.
> June 25th-27th - (Approximately assuming RC passes) put the RC up for
> a vote to IPMC
>
> I am happy to drive this forward.
>
> --Brennan

Re: Release 9.1

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

On Wed, Jun 3, 2020 at 2:12 PM Abdelatif Guettouche
<ab...@gmail.com> wrote:
> Generating release notes is the part that has the most painful work,
> it took 4 of us last time to get it done.  I still wonder if there is
> a way to automate that, maybe with good PR summaries and consistent
> labeling.
> Nathan created a confluence page to prepare release notes for the 9.1
> ahead of time.

Alright now that we at least have a draft of the release notes for
both the OS and Apps I would propose this timeline:
June 7-15th - Focus on stabilizing and any outstanding features that
we can close out
June 15th - Create the release branch 9.1 and ask for testing on that
branch and refine the release notes
June 22th - Cut RC0 and put it up for a vote to PPMC, if people are
feeling comfortable with the level of testing we can move this up, but
let's really try to get some testing in.
June 25th-27th - (Approximately assuming RC passes) put the RC up for
a vote to IPMC

I am happy to drive this forward.

--Brennan

Re: Release 9.1

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

I only mentioned macOS because one of the mentors was using it the
last time, I guess what's important is to have instructions that start
from a fresh installation of any OS and end with a usable workstation,
I'm sure there are plenty for Linux.

> Re: the release notes, maybe we can start using a template for PR text?
> That would make going through them easier. For instance:

We already have a PR template similar to that, we just need to
convince everyone to use it.
The majority do use it, but it's still being ignored for small changes.


On Wed, Jun 3, 2020 at 10:36 PM Adam Feuer <ad...@starcat.io> wrote:
>
> Abdelatif,
>
> I haven't tried my instructions on macOS... when I was first starting out,
> I got stuck, and switched to Linux. But I will give macOS a try again in
> the next few days, and update the instructions if I succeed. Good idea.
>
> Re: the release notes, maybe we can start using a template for PR text?
> That would make going through them easier. For instance:
>
> ### Bug or Feature?
> ### One line summary
> ### Impact
> ### Limitations / TODO
> ### Detail
> ### Testing
>
> If we had this filled out for every PR, it would make creating the Release
> Notes a lot easier.
>
> -adam
>
> On Wed, Jun 3, 2020 at 2:12 PM Abdelatif Guettouche <
> abdelatif.guettouche@gmail.com> wrote:
>
> > For the licensing, we are taking baby steps by changing only the files
> > that we know won't cause any issue.
> > I think we will continue to do that until we get the necessary ICLAs
> > then we can do a massive substitution.
> > But as have been said in the very beginning, this should not stop us
> > from making releases.
> > The most important part is that we make progress with each release.
> > We are definitely making progress technically, what Brennan is
> > referring to is the fact that IPMC members found it hard to build from
> > source.  I think most of their issues came from not
> > installing/configuring kconfig-frontends which is in a separate
> > repository.
> > BTW, Adam, have you tried the steps of your companion in a fresh
> > installation of, say, macOS?  That might be all we need.
> >
> > Generating release notes is the part that has the most painful work,
> > it took 4 of us last time to get it done.  I still wonder if there is
> > a way to automate that, maybe with good PR summaries and consistent
> > labeling.
> > Nathan created a confluence page to prepare release notes for the 9.1
> > ahead of time.
> >
> > On Wed, Jun 3, 2020 at 4:58 PM Adam Feuer <ad...@starcat.io> wrote:
> > >
> > > Brennan,
> > >
> > > What, in your opinion, needs to be done to improve the onboarding
> > process?
> > >
> > > And what would you like to see happen to improve the licensing issues?
> > > Another pass through the files of another section (like we did with
> > sched)
> > > and updating headers? Or...?
> > >
> > > -adam
> > >
> > > On Wed, Jun 3, 2020 at 8:44 AM Brennan Ashton <bashton@brennanashton.com
> > >
> > > wrote:
> > >
> > > > On Wed, Jun 3, 2020, 6:16 AM Gregory Nutt <sp...@gmail.com> wrote:
> > > >
> > > > > Hi, all
> > > > >
> > > > > If we are serious about getting on a two month release cycle again,
> > now
> > > > > is the time to begin thinking about the 9.1 release. We created the
> > 9.0
> > > > > release branch sometime before the 15th of April.   We signed the
> > > > > release on April 23rd.  So we have some time, but also we need to
> > start
> > > > > get some plans and organization in place.  And we need to think about
> > > > > doing everything we can to make the master stable for that branch.
> > We
> > > > > should hold off large, sweeping changes until we get past that point.
> > > > >
> > > > > Duo... you mentioned that you were interested with assisted with the
> > > > > releases?  Abdelatif was the point man last time.  Perhaps you would
> > > > > want to discuss his experiences with him?
> > > > >
> > > > > Greg
> > > > >
> > > >
> > > > I would agree, but we have made zero progress on improving the
> > onboarding
> > > > process in terms of build and documentation, nor have we made progress
> > on
> > > > the licensing process. I'm not confident that the release would pass.
> > > >
> > > > I am also happy to share more on the steps of the actual release
> > process
> > > > outside of the release notes and branching (thank you Abdelatif that
> > was a
> > > > lot of work) if someone wants to take that on, or I can offer to do
> > that
> > > > portion again. I am happy to do it. It's a lot of little steps but
> > none of
> > > > them are that complicated.
> > > >
> > > > --Brennan
> > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Adam Feuer <ad...@starcat.io>
> >
>
>
> --
> Adam Feuer <ad...@starcat.io>

Re: Release 9.1

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

On Wed, Jun 3, 2020 at 5:36 PM Adam Feuer <ad...@starcat.io> wrote:

> I got stuck, and switched to Linux. But I will give macOS a try again in
> the next few days, and update the instructions if I succeed.


I built a recent master on macOS and it worked. All I had to do was:

* Install gcc-arm-none-eabi using instructions from either PX4 or Mynewt
(don't remember which),

>
* Install flock using instructions in our top level readme

* configure && make && make install kconfig-frontends from our tools repo

and after that, 'tools/configure.sh', 'make menuconfig', and 'make' worked
perfectly. One caveat: I have Xcode and its command line tools, and
homebrew, so maybe I have something not mentioned here that's needed.

Nathan

Re: Release 9.1

[Adam Feuer <ad...@starcat.io>]

Abdelatif,

I haven't tried my instructions on macOS... when I was first starting out,
I got stuck, and switched to Linux. But I will give macOS a try again in
the next few days, and update the instructions if I succeed. Good idea.

Re: the release notes, maybe we can start using a template for PR text?
That would make going through them easier. For instance:

### Bug or Feature?
### One line summary
### Impact
### Limitations / TODO
### Detail
### Testing

If we had this filled out for every PR, it would make creating the Release
Notes a lot easier.

-adam

On Wed, Jun 3, 2020 at 2:12 PM Abdelatif Guettouche <
abdelatif.guettouche@gmail.com> wrote:

> For the licensing, we are taking baby steps by changing only the files
> that we know won't cause any issue.
> I think we will continue to do that until we get the necessary ICLAs
> then we can do a massive substitution.
> But as have been said in the very beginning, this should not stop us
> from making releases.
> The most important part is that we make progress with each release.
> We are definitely making progress technically, what Brennan is
> referring to is the fact that IPMC members found it hard to build from
> source.  I think most of their issues came from not
> installing/configuring kconfig-frontends which is in a separate
> repository.
> BTW, Adam, have you tried the steps of your companion in a fresh
> installation of, say, macOS?  That might be all we need.
>
> Generating release notes is the part that has the most painful work,
> it took 4 of us last time to get it done.  I still wonder if there is
> a way to automate that, maybe with good PR summaries and consistent
> labeling.
> Nathan created a confluence page to prepare release notes for the 9.1
> ahead of time.
>
> On Wed, Jun 3, 2020 at 4:58 PM Adam Feuer <ad...@starcat.io> wrote:
> >
> > Brennan,
> >
> > What, in your opinion, needs to be done to improve the onboarding
> process?
> >
> > And what would you like to see happen to improve the licensing issues?
> > Another pass through the files of another section (like we did with
> sched)
> > and updating headers? Or...?
> >
> > -adam
> >
> > On Wed, Jun 3, 2020 at 8:44 AM Brennan Ashton <bashton@brennanashton.com
> >
> > wrote:
> >
> > > On Wed, Jun 3, 2020, 6:16 AM Gregory Nutt <sp...@gmail.com> wrote:
> > >
> > > > Hi, all
> > > >
> > > > If we are serious about getting on a two month release cycle again,
> now
> > > > is the time to begin thinking about the 9.1 release. We created the
> 9.0
> > > > release branch sometime before the 15th of April.   We signed the
> > > > release on April 23rd.  So we have some time, but also we need to
> start
> > > > get some plans and organization in place.  And we need to think about
> > > > doing everything we can to make the master stable for that branch.
> We
> > > > should hold off large, sweeping changes until we get past that point.
> > > >
> > > > Duo... you mentioned that you were interested with assisted with the
> > > > releases?  Abdelatif was the point man last time.  Perhaps you would
> > > > want to discuss his experiences with him?
> > > >
> > > > Greg
> > > >
> > >
> > > I would agree, but we have made zero progress on improving the
> onboarding
> > > process in terms of build and documentation, nor have we made progress
> on
> > > the licensing process. I'm not confident that the release would pass.
> > >
> > > I am also happy to share more on the steps of the actual release
> process
> > > outside of the release notes and branching (thank you Abdelatif that
> was a
> > > lot of work) if someone wants to take that on, or I can offer to do
> that
> > > portion again. I am happy to do it. It's a lot of little steps but
> none of
> > > them are that complicated.
> > >
> > > --Brennan
> > >
> > > >
> > >
> >
> >
> > --
> > Adam Feuer <ad...@starcat.io>
>


-- 
Adam Feuer <ad...@starcat.io>

Re: Release 9.1

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

For the licensing, we are taking baby steps by changing only the files
that we know won't cause any issue.
I think we will continue to do that until we get the necessary ICLAs
then we can do a massive substitution.
But as have been said in the very beginning, this should not stop us
from making releases.
The most important part is that we make progress with each release.
We are definitely making progress technically, what Brennan is
referring to is the fact that IPMC members found it hard to build from
source.  I think most of their issues came from not
installing/configuring kconfig-frontends which is in a separate
repository.
BTW, Adam, have you tried the steps of your companion in a fresh
installation of, say, macOS?  That might be all we need.

Generating release notes is the part that has the most painful work,
it took 4 of us last time to get it done.  I still wonder if there is
a way to automate that, maybe with good PR summaries and consistent
labeling.
Nathan created a confluence page to prepare release notes for the 9.1
ahead of time.

On Wed, Jun 3, 2020 at 4:58 PM Adam Feuer <ad...@starcat.io> wrote:
>
> Brennan,
>
> What, in your opinion, needs to be done to improve the onboarding process?
>
> And what would you like to see happen to improve the licensing issues?
> Another pass through the files of another section (like we did with sched)
> and updating headers? Or...?
>
> -adam
>
> On Wed, Jun 3, 2020 at 8:44 AM Brennan Ashton <ba...@brennanashton.com>
> wrote:
>
> > On Wed, Jun 3, 2020, 6:16 AM Gregory Nutt <sp...@gmail.com> wrote:
> >
> > > Hi, all
> > >
> > > If we are serious about getting on a two month release cycle again, now
> > > is the time to begin thinking about the 9.1 release. We created the 9.0
> > > release branch sometime before the 15th of April.   We signed the
> > > release on April 23rd.  So we have some time, but also we need to start
> > > get some plans and organization in place.  And we need to think about
> > > doing everything we can to make the master stable for that branch.  We
> > > should hold off large, sweeping changes until we get past that point.
> > >
> > > Duo... you mentioned that you were interested with assisted with the
> > > releases?  Abdelatif was the point man last time.  Perhaps you would
> > > want to discuss his experiences with him?
> > >
> > > Greg
> > >
> >
> > I would agree, but we have made zero progress on improving the onboarding
> > process in terms of build and documentation, nor have we made progress on
> > the licensing process. I'm not confident that the release would pass.
> >
> > I am also happy to share more on the steps of the actual release process
> > outside of the release notes and branching (thank you Abdelatif that was a
> > lot of work) if someone wants to take that on, or I can offer to do that
> > portion again. I am happy to do it. It's a lot of little steps but none of
> > them are that complicated.
> >
> > --Brennan
> >
> > >
> >
>
>
> --
> Adam Feuer <ad...@starcat.io>

Re: Release 9.1

[Adam Feuer <ad...@starcat.io>]

Brennan,

What, in your opinion, needs to be done to improve the onboarding process?

And what would you like to see happen to improve the licensing issues?
Another pass through the files of another section (like we did with sched)
and updating headers? Or...?

-adam

On Wed, Jun 3, 2020 at 8:44 AM Brennan Ashton <ba...@brennanashton.com>
wrote:

> On Wed, Jun 3, 2020, 6:16 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> > Hi, all
> >
> > If we are serious about getting on a two month release cycle again, now
> > is the time to begin thinking about the 9.1 release. We created the 9.0
> > release branch sometime before the 15th of April.   We signed the
> > release on April 23rd.  So we have some time, but also we need to start
> > get some plans and organization in place.  And we need to think about
> > doing everything we can to make the master stable for that branch.  We
> > should hold off large, sweeping changes until we get past that point.
> >
> > Duo... you mentioned that you were interested with assisted with the
> > releases?  Abdelatif was the point man last time.  Perhaps you would
> > want to discuss his experiences with him?
> >
> > Greg
> >
>
> I would agree, but we have made zero progress on improving the onboarding
> process in terms of build and documentation, nor have we made progress on
> the licensing process. I'm not confident that the release would pass.
>
> I am also happy to share more on the steps of the actual release process
> outside of the release notes and branching (thank you Abdelatif that was a
> lot of work) if someone wants to take that on, or I can offer to do that
> portion again. I am happy to do it. It's a lot of little steps but none of
> them are that complicated.
>
> --Brennan
>
> >
>


-- 
Adam Feuer <ad...@starcat.io>

Re: Release 9.1

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

On Wed, Jun 3, 2020, 6:16 AM Gregory Nutt <sp...@gmail.com> wrote:

> Hi, all
>
> If we are serious about getting on a two month release cycle again, now
> is the time to begin thinking about the 9.1 release. We created the 9.0
> release branch sometime before the 15th of April.   We signed the
> release on April 23rd.  So we have some time, but also we need to start
> get some plans and organization in place.  And we need to think about
> doing everything we can to make the master stable for that branch.  We
> should hold off large, sweeping changes until we get past that point.
>
> Duo... you mentioned that you were interested with assisted with the
> releases?  Abdelatif was the point man last time.  Perhaps you would
> want to discuss his experiences with him?
>
> Greg
>

I would agree, but we have made zero progress on improving the onboarding
process in terms of build and documentation, nor have we made progress on
the licensing process. I'm not confident that the release would pass.

I am also happy to share more on the steps of the actual release process
outside of the release notes and branching (thank you Abdelatif that was a
lot of work) if someone wants to take that on, or I can offer to do that
portion again. I am happy to do it. It's a lot of little steps but none of
them are that complicated.

--Brennan

>