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 t
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 pu
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
> 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 t
> 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.
Hi,
> The tarballs should be uploaded to [1] and/or [2] right?
Correct. I’ve created them for you.
Thanks,
Justin
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 ar
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, r
> 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
>
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 an
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
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 t
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 tar
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
> >> unimportan
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
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
> 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:
> 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 wit
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
We need to make the release candidate tarballs and put them up for
testing/signing, and give people a couple of weeks to test them. I
guess we aren't going to make the April 30 release but we're all still
learning and trying to figure out the process. Just as we had trouble
with other things in
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 read
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 ag
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
On Mon, Apr 20, 2020 at 10:34 AM Gregory Nutt wrote:
> 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.
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 pi
> 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 t
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.
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 th
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/imxrt1
I think it's about time we called for a vote.
Each vote will last 72h, it's tight for a 30 April release, we don't
have much room for another round.
I backported last night few more PRs, no functional changes, typos and
release notes.
I guess the only one remaining is 757.
On Sat, Apr 18, 2020 at
On Sat, Apr 18, 2020, 12:27 PM Gregory Nutt wrote:
>
> 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 br
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
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 wi
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,
> 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
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 Abd
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 mul
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?
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 relea
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
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
c
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 Fr
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,
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.
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 an
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. 2
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:
> A
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 me
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,
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 w
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
> 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 perso
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
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
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
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
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 w
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 w
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
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 diff
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
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, t
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 docume
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.
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: 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:
>
> > Perha
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
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
>
> 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-r
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
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.
72 matches
Mail list logo
