You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Gregory Nutt <sp...@gmail.com> on 2020/01/07 22:09:36 UTC
Side-effects of removing (void)
The removal of (void) from all functions whose return value has been
ignored has introduced several new warnings into the build test output.
For example in lpc3_appinit(), I now see this:
# define nsh_spifi_initialize() (OK)
and
nsh_spifi_initialize();
which now generates a new warning: "warning: statement with no effect
[-Wunused-value]"
Greg
Re: Side-effects of removing (void)
Posted by Xiang Xiao <xi...@gmail.com>.
On Mon, Jan 13, 2020 at 8:32 AM Gregory Nutt <sp...@gmail.com> wrote:
>
>
> >
> >> So I guess our choices are:
> >>
> >> 1. Reinstate (void) only where the warning occurs.
> >>
> >> 2. Reinstate (void) everywhere return values aren't checked. What a
> >> nightmare.
> >>
> >> 3. Change defines such as the above to static inline functions.
> >> Disadvantage: The inline keyword is not in the C89 standard.
> >
> > I have ran the build tests and do not know of any other cases like
> > this. Certainly, a few more might show up but it is not an endemic
> > problem at the moment.
> >
> > At its worst, it is only a warning.
>
> The real problem here is not really that we may (or may not have) opened
> up a bunch of new warnings. The issue here is that our QA process
> sucks. We make enormous changes like this and commit it to master
> without so little as verifying that the code compiles and or that it
> builds without introducing new warnings. The code is just changed and
> "thrown over the fence."
>
> This is total unprofessional and must come to a stop. The way to bring
> this to a stop is to complete the workflow definition and the
> implementation of some nightly builld-everything step that has to happen
> before any PR is committed. The fix is to improve our QA processes so
> that this cannot happen.
>
> But we have, apparently, lost interest in the workflow. Apparently,
> Haitao Liu is working on something, but that is a black box. We have no
> visibility of what is happening, what is being done in detail, when it
> will be rolled out, or how it integrates with the unfinished workflow.
>
Haitao is trying to create the jenkins job which will run all builtin
config: any build error either get fixed or config should be remove
from repo.
The integration is simple: each commit MUST pass the build check
before it can merge into mainline.
> Greg
>
>
>
Re: Side-effects of removing (void)
Posted by Gregory Nutt <sp...@gmail.com>.
>
>> So I guess our choices are:
>>
>> 1. Reinstate (void) only where the warning occurs.
>>
>> 2. Reinstate (void) everywhere return values aren't checked. What a
>> nightmare.
>>
>> 3. Change defines such as the above to static inline functions.
>> Disadvantage: The inline keyword is not in the C89 standard.
>
> I have ran the build tests and do not know of any other cases like
> this. Certainly, a few more might show up but it is not an endemic
> problem at the moment.
>
> At its worst, it is only a warning.
The real problem here is not really that we may (or may not have) opened
up a bunch of new warnings. The issue here is that our QA process
sucks. We make enormous changes like this and commit it to master
without so little as verifying that the code compiles and or that it
builds without introducing new warnings. The code is just changed and
"thrown over the fence."
This is total unprofessional and must come to a stop. The way to bring
this to a stop is to complete the workflow definition and the
implementation of some nightly builld-everything step that has to happen
before any PR is committed. The fix is to improve our QA processes so
that this cannot happen.
But we have, apparently, lost interest in the workflow. Apparently,
Haitao Liu is working on something, but that is a black box. We have no
visibility of what is happening, what is being done in detail, when it
will be rolled out, or how it integrates with the unfinished workflow.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> When should we do this first Apache release? How do we do this? Who is the release manager? (hint: not me) Since the breakage is coming on a daily basis, how/when can we get a stable enough system to even consider a release.
Af far as an Apache release is concerned there is a set of thing that are needed, having the code work is actually not one of them. Although you and your users may care about that.
I would suggest you make a checklist for your release along the lines of this one. [1] The first decision to be made would is going to be how to deal with the file headers, and the next the disclaimer and license and notice [5] file. It going to take a lot of work to get this right, the good news is if you use the work in progress disclaimer [2] you can put off some of this work until later releases. I suggest everyone reads the ASF release management [3] and distribution [4] policies.
Thanks,
Justin
1. https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist
2. https://incubator.apache.org/policy/incubation.html#work_in_progress_disclaimer
3. https://incubator.apache.org/guides/releasemanagement.html
4. https://www.apache.org/dev/release-distribution.html
5. http://www.apache.org/dev/licensing-howto.html
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
Also, I think that the build was fixed late today. I have verified most
configurations. I had to submit several PRs today for build problems,
compile errors and new warnings, but I think we do, finally, have a
clean build. But I do need to re-verify everything from beginning to
end tomorrow.
Let's be more careful, folks. This behavior too destructive!
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
>
>> The point I'd like to make, is that I'd much rather the whole world stop
>> turning, nothing get merged into master until we sort out the process;
>> rather than allow anything to break master. I'd like for us to adopt a
>> philosophy that "Nothing is worse than breaking Master." Now, that's
>> just
>> me, I welcome counterarguments (and even flames).
>
> Nothing in the process is particularly different at present than in
> the past. Several unverified PRs came in close together in time.
> Since each broke the build and were separated over time, the build
> remained broken for a couple weeks or more.
>
> There is nothing significantly different in the process from when when
> patches were added in the same manner. Users are simply not acting
> responsibly right now and are not verifying the changes before
> committing them (it appears, in cases, that they are not even
> compiling them!). That behavior has to stop.
>
> We were just luckier in the past and I think people were more careful
> when they had to work up patches vs. just pushing a button to create a
> PR. The ease of creating PRs with one finger leads to sloppiness.
That being said, the solution is the same: We need automated checks to
assure, at a minimum, that there is no build breakage. But there is no
new crisis. This is the same situation as in the past.
So I see no real reason to do anything differently except to ask people
to please very the changes before you push the button and submit the
PR. We aren't in that big of a rush. Test it, build it. Get some
confidence first. Then, and only then, fire off the PR.
Meanwhile, in parallel we can get some automated verification in place.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> This just our internal test,and share in Wechat, not the final report.
What is this conversation happening in WeChat? It needs to be on the mailing list. It’s fine to use WeCat for casual conversation but anything that affects the project needs to be brought back to this mailing list.
> We need get the manager approve before we can send the official
> announcement. Also why I should report our internal conversation
> publicly?
All conversations about the project need to be open and transparent and occur in public. They need to be in a place that is searchable and archivable. I can't imagine any reason for a conversation like this would need to be private, but I don’t know the exact details. Other PPMC members and your mentors need to be aware of what is going on and if they are aware they can help. For instance, have you involved Infra in these dicusssions?
Let say for some reason, it didn’t get approval from your manager if that conversation was public, another individual (or more than one) may be able to step and help out and donate the needed resources instead. Or it might even be possible that there's no need to donate anything and Infra can provide the resources you need.
Thanks,
Justin
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> We need get the manager approve before we can send the official announcement.
Also this is something the whole PPMC need to be involved in and make a decision on before any announcement is made.
I’m a little unclear what context you mean as an announcement there, incubating project need to take care with publicity, please see [1], note that "No formal press releases or announcements of any kind are allowed to be disseminated on any newswire service during the Incubation process."
Thanks,
Justin
1. https://incubator.apache.org/guides/publicity.html
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Xiang Xiao <xi...@gmail.com>.
On Wed, Jan 15, 2020 at 5:54 AM Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> > The report from Haitao show that all arm 400 config can build within
> > 94min with his machine
>
> What report? Where can I find this?
>
This just our internal test,and share in Wechat, not the final report.
I shared this information just let the community know how much
workload we need to support the full build.
> > We are discussing internally to donate several build machines to
> > ensure all build could finish within half hour.
>
> Why is this conversation not happing on this list?
>
We need get the manager approve before we can send the official
announcement. Also why I should report our internal conversation
publicly? I think that we share the final information(e.g. we donate
two servers to ASF) is enough, is it right?
> Thanks,
> Justin
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The report from Haitao show that all arm 400 config can build within
> 94min with his machine
What report? Where can I find this?
> We are discussing internally to donate several build machines to
> ensure all build could finish within half hour.
Why is this conversation not happing on this list?
Thanks,
Justin
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Xiang Xiao <xi...@gmail.com>.
On Wed, Jan 15, 2020 at 2:21 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> Hi, Xiang,
> > Since NuttX use Kconfig system, the simple pull/apply/compile cycle
> > isn't enough to catch all possible error. Actually, all my commits
> > pass our local automation build(four config: sim, armv7-m, armv8-m and
> > armv7-a) before PR sent out.
>
> It is hard to imagine how they could have passed with typos in errno
> values for example. Perhaps your configurations just did not build the
> files that generated the compilation errors. We really have to build
> many, many configurations to have confidence that the change does not
> break anything.
Yes, that's typo errors just happened when the write buffer isn't
enable, all our config enable the write buffer unfortunately.
>
> We have an obligation to assure our users the EVERY configuration that
> is included in the release builds correctly. Not some of them, not most
> of them, not a representative set of them, but ALL of them.
>
> I had a similar issues one an nxstyle commit recently. Nxstyle built
> fine under Cygwin, but failed to build under Linux. It needed to
> include stdint.h. That inclusion was not necessary under Cygwin perhaps
> because stdint.h was included indirectly through some other header file.
>
> > Haitao is preparing the jenkins job to run all possible config, but
> > the config number is huge, we need to donate several powerful severs
> > to ensure the precheck can finish in half hour.
>
> If we use a smaller set to qualify a PR for merging, then I think we
> would be okay. We could then run the entire set of configurations
> asynchronously to assure that all configurations build.
>
> Of course, there will be some errors: Some cases where a PR builds in
> the smaller set of configurations, but not for the entire set. That
> case would be rarer and should not affect so many users. Any problems
> found with the entire set build could be fixed by the next day. That
> seems like a reasonable compromise.
The report from Haitao show that all arm 400 config can build within
94min with his machine, so I think it is reasonable to achieve half
hour goal by:
1.Enable more optimaition(e.g. ccache, ramdisk...)
2.Use more powerful machine(e.g. big memory, more cpu core and fast SSD)
And we can use one Linux machine build all arm config, and anthor
Windows machine build the rest config with cygwin, msys, wsl.
We are discussing internally to donate several build machines to
ensure all build could finish within half hour.
>
> Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
Hi, Xiang,
> Since NuttX use Kconfig system, the simple pull/apply/compile cycle
> isn't enough to catch all possible error. Actually, all my commits
> pass our local automation build(four config: sim, armv7-m, armv8-m and
> armv7-a) before PR sent out.
It is hard to imagine how they could have passed with typos in errno
values for example. Perhaps your configurations just did not build the
files that generated the compilation errors. We really have to build
many, many configurations to have confidence that the change does not
break anything.
We have an obligation to assure our users the EVERY configuration that
is included in the release builds correctly. Not some of them, not most
of them, not a representative set of them, but ALL of them.
I had a similar issues one an nxstyle commit recently. Nxstyle built
fine under Cygwin, but failed to build under Linux. It needed to
include stdint.h. That inclusion was not necessary under Cygwin perhaps
because stdint.h was included indirectly through some other header file.
> Haitao is preparing the jenkins job to run all possible config, but
> the config number is huge, we need to donate several powerful severs
> to ensure the precheck can finish in half hour.
If we use a smaller set to qualify a PR for merging, then I think we
would be okay. We could then run the entire set of configurations
asynchronously to assure that all configurations build.
Of course, there will be some errors: Some cases where a PR builds in
the smaller set of configurations, but not for the entire set. That
case would be rarer and should not affect so many users. Any problems
found with the entire set build could be fixed by the next day. That
seems like a reasonable compromise.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Alin Jerpelea <je...@gmail.com>.
I can not offer my machine but I can offer the service as a private
contributor
Alin
On Thu, Jan 16, 2020 at 10:12 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> HI,
>
> Projects can have their own resources but we would prefer that they were
> (for security and continuity reasons) maintained by Infra. If you want too
> donate a build machine to Infra you need to involve them in the
> conversation as I’ve previously mentioned. This would also need to be
> agreed to by the PPMC.
>
> Thanks,
> Justin
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
Projects can have their own resources but we would prefer that they were (for security and continuity reasons) maintained by Infra. If you want too donate a build machine to Infra you need to involve them in the conversation as I’ve previously mentioned. This would also need to be agreed to by the PPMC.
Thanks,
Justin
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Xiang Xiao <xi...@gmail.com>.
If my understanding is correct, the machine need donate to ASF, is that correct?
On Thu, Jan 16, 2020 at 7:25 PM Alin Jerpelea <je...@gmail.com> wrote:
>
> I can offer testing setup with a machine that builds daily all configs and
> exports the logs on github help us spot the issues?
>
> Alin
>
>
> On Wed, Jan 15, 2020 at 1:02 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> > Well, we still don't have a clean build yet 8( I got to configuration
> > 342 out of the 420 then it failed on a THTTP + binfs build what has
> > worked for years (olimex-lpc1766stk:thttpd-binfs). No idea while. I
> > will look into that tomorrow.
> >
> > Greg
> >
> >
> >
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Alin Jerpelea <je...@gmail.com>.
I can offer testing setup with a machine that builds daily all configs and
exports the logs on github help us spot the issues?
Alin
On Wed, Jan 15, 2020 at 1:02 AM Gregory Nutt <sp...@gmail.com> wrote:
> Well, we still don't have a clean build yet 8( I got to configuration
> 342 out of the 420 then it failed on a THTTP + binfs build what has
> worked for years (olimex-lpc1766stk:thttpd-binfs). No idea while. I
> will look into that tomorrow.
>
> Greg
>
>
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
Well, we still don't have a clean build yet 8( I got to configuration
342 out of the 420 then it failed on a THTTP + binfs build what has
worked for years (olimex-lpc1766stk:thttpd-binfs). No idea while. I
will look into that tomorrow.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
> Yes, it's great that we develop a tool to generate all possible
> combination of affected options smartly.
It would be difficult to cover them all due to things like mutually
exclusive "choice" and dependencies. But if we could generate a tool
that generated all possible configurations (assuming for a single
board), then that could be very valuable.
> Like Nanthan suggestion, we can create a special config to enable all
> non-execlusive options, actually kconfig support --allyesconfig to
> simplify this task.
I am not sure if that is useful or not. Certainly not for bool settings
whose default is already "yes
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Speaking of LINT, another avenue might be static analysis, which finds all
> kinds of common errors. That is imperfect and comes with false negatives
> but is useful nonetheless.
Apache projects have access to this [1]. I used it in the past to good effect.
It does support C projects. e.g [2] for all Apache projects see [3].
Thanks,
Justin
1. https://cwiki.apache.org/confluence/display/INFRA/SonarQube+Analysis
2. https://sonarcloud.io/dashboard?id=milagro
3. https://sonarcloud.io/organizations/apache/projects
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Xiang Xiao <xi...@gmail.com>.
On Wed, Jan 15, 2020 at 3:01 AM Gregory Nutt <sp...@gmail.com> wrote:
>
>
> > Haitao is preparing the jenkins job to run all possible config, but
> > the config number is huge, we need to donate several powerful severs
> > to ensure the precheck can finish in half hour.
>
> I am repeating myself, but it is worth remembering.
>
> There might not be any configuration in the repository that builds the
> code that is changed by a PR! The code could be totally broken and
> could fail the first time you compile it, but if there is no
> configuration in the repository that has the configuration settings
> needed to build all options for the changed code, you will never know it.
>
> It is for this reason that have been arguing that we need a smarter test
> than just building a set of configurations. The smaller the set the
> more likely that they will not build the affected code at all! Then
> the build test is completely useless.
>
Yes, it's great that we develop a tool to generate all possible
combination of affected options smartly.
> I very typical example is when someone develops a new driver for some
> "FooBar" hardware. It is enabled by CONFIG_DRIVER_FOOBAR. But there is
> no defconfig file under boards that includes CONFIG_DRIVER_FOOBAR=y. As
> a result, any kind of canned build test is a waste of time and will not
> prove or disprove the syntactic correctness of the file -- since it
> never builds it.
>
Like Nanthan suggestion, we can create a special config to enable all
non-execlusive options, actually kconfig support --allyesconfig to
simplify this task.
> I have suggested that we ask the contributor to provide a list of every
> configuration option that needs to be set/unset to verify all
> combinations of the changed code. Then we use those configuration
> options to select all relevant configurations.
>
> Perhaps we could grep the modified files to get those options?
>
> In the case that there is no configuration in the repository that select
> those configuration options, we would need to ask the contributor to
> provide a test configuration.
>
> Anything that is random, hit or miss would be, most likely, a waste of time.
>
> Greg
>
>
>
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Jan 14, 2020 at 2:01 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> > Haitao is preparing the jenkins job to run all possible config, but
> > the config number is huge, we need to donate several powerful severs
> > to ensure the precheck can finish in half hour.
>
> I am repeating myself, but it is worth remembering.
>
> There might not be any configuration in the repository that builds the
> code that is changed by a PR! The code could be totally broken and
> could fail the first time you compile it, but if there is no
> configuration in the repository that has the configuration settings
> needed to build all options for the changed code, you will never know it.
>
> It is for this reason that have been arguing that we need a smarter test
> than just building a set of configurations. The smaller the set the
> more likely that they will not build the affected code at all! Then
> the build test is completely useless.
>
> I very typical example is when someone develops a new driver for some
> "FooBar" hardware. It is enabled by CONFIG_DRIVER_FOOBAR. But there is
> no defconfig file under boards that includes CONFIG_DRIVER_FOOBAR=y. As
> a result, any kind of canned build test is a waste of time and will not
> prove or disprove the syntactic correctness of the file -- since it
> never builds it.
>
> I have suggested that we ask the contributor to provide a list of every
> configuration option that needs to be set/unset to verify all
> combinations of the changed code. Then we use those configuration
> options to select all relevant configurations.
>
> Perhaps we could grep the modified files to get those options?
>
> In the case that there is no configuration in the repository that select
> those configuration options, we would need to ask the contributor to
> provide a test configuration.
>
> Anything that is random, hit or miss would be, most likely, a waste of
> time.
I don't know how they do it now, but back in the day I remember that the
FreeBSD project had a configuration that is not valid for running, but
which builds ALL options (including, I presume, options that should be
mutually exclusive), to catch build errors. I think it was called something
with LINT in the name. Maybe that's one of the avenues we could consider,
in parallel with other build tests of valid configurations.
Speaking of LINT, another avenue might be static analysis, which finds all
kinds of common errors. That is imperfect and comes with false negatives
but is useful nonetheless.
Nathan
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
> Haitao is preparing the jenkins job to run all possible config, but
> the config number is huge, we need to donate several powerful severs
> to ensure the precheck can finish in half hour.
I am repeating myself, but it is worth remembering.
There might not be any configuration in the repository that builds the
code that is changed by a PR! The code could be totally broken and
could fail the first time you compile it, but if there is no
configuration in the repository that has the configuration settings
needed to build all options for the changed code, you will never know it.
It is for this reason that have been arguing that we need a smarter test
than just building a set of configurations. The smaller the set the
more likely that they will not build the affected code at all! Then
the build test is completely useless.
I very typical example is when someone develops a new driver for some
"FooBar" hardware. It is enabled by CONFIG_DRIVER_FOOBAR. But there is
no defconfig file under boards that includes CONFIG_DRIVER_FOOBAR=y. As
a result, any kind of canned build test is a waste of time and will not
prove or disprove the syntactic correctness of the file -- since it
never builds it.
I have suggested that we ask the contributor to provide a list of every
configuration option that needs to be set/unset to verify all
combinations of the changed code. Then we use those configuration
options to select all relevant configurations.
Perhaps we could grep the modified files to get those options?
In the case that there is no configuration in the repository that select
those configuration options, we would need to ask the contributor to
provide a test configuration.
Anything that is random, hit or miss would be, most likely, a waste of time.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
> How about just collecting a bunch of commonly used configurations from
> users? Maybe using the example configs that are in the repo now, but
> adapting them to be run on the version that is being run in Jenkins...?
> That is not perfect, but even having 10-20 example configs would be better
> than 1. :)
That would reduce the time but would not find all of the errors.
Sometimes I build 300 or so configurations before I see the first failure.
We need to build more configurations to catch more problems, not fewer.
I think fewer would be okay for a pre-commit check, provided that the
entire set were built at least once per day. I have no idea how you
would pick a representative subset. Maybe it would be best to select
them randomly on each PR?
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Adam Feuer <ad...@starcat.io>.
Xiang,
How about just collecting a bunch of commonly used configurations from
users? Maybe using the example configs that are in the repo now, but
adapting them to be run on the version that is being run in Jenkins...?
That is not perfect, but even having 10-20 example configs would be better
than 1. :)
cheers
adam
On Tue, Jan 14, 2020 at 9:22 AM Xiang Xiao <xi...@gmail.com>
wrote:
> Since NuttX use Kconfig system, the simple pull/apply/compile cycle
> isn't enough to catch all possible error. Actually, all my commits
> pass our local automation build(four config: sim, armv7-m, armv8-m and
> armv7-a) before PR sent out.
> Haitao is preparing the jenkins job to run all possible config, but
> the config number is huge, we need to donate several powerful severs
> to ensure the precheck can finish in half hour.
>
> Thanks
> Xiang
>
> On Tue, Jan 14, 2020 at 10:37 PM Alin Jerpelea <je...@gmail.com> wrote:
> >
> > Just a small checklist before pushing.!
> >
> > 1 *pull master*
> > 2. add your patch(es)
> > 3.* compile*
> > 4 make distclean
> > 5.* PUSH*
> >
> > Let's hope that we avoid having it broken again
> >
> > On our side as commiters, before the automation is ready, we should
> > cherry-pick and build before pressing the merge button
> > Can we all do that ?
> >
> > //Alin
> >
> >
> > On Tue, Jan 14, 2020, 15:15 David Sidrane <Da...@nscdg.com>
> wrote:
> >
> > > The NuttX project is still misusing the tools.
> > > It is not the PR. It is the process (or lack of one)
> > >
> > > To solve this problem:
> > >
> > > Build the PR on top of master BEFORE merging.
> > > Do not MERGE until PR on master builds.
> > >
> > > David
> > >
> > > -----Original Message-----
> > > From: Gregory Nutt [mailto:spudaneco@gmail.com]
> > > Sent: Monday, January 13, 2020 6:00 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: Apache Code Relese (Was Re: Side-effects of removing
> (void))
> > >
> > >
> > > > The point I'd like to make, is that I'd much rather the whole world
> stop
> > > > turning, nothing get merged into master until we sort out the
> process;
> > > > rather than allow anything to break master. I'd like for us to
> adopt a
> > > > philosophy that "Nothing is worse than breaking Master." Now, that's
> > > just
> > > > me, I welcome counterarguments (and even flames).
> > >
> > > Nothing in the process is particularly different at present than in the
> > > past. Several unverified PRs came in close together in time. Since
> > > each broke the build and were separated over time, the build remained
> > > broken for a couple weeks or more.
> > >
> > > There is nothing significantly different in the process from when when
> > > patches were added in the same manner. Users are simply not acting
> > > responsibly right now and are not verifying the changes before
> > > committing them (it appears, in cases, that they are not even compiling
> > > them!). That behavior has to stop.
> > >
> > > We were just luckier in the past and I think people were more careful
> > > when they had to work up patches vs. just pushing a button to create a
> > > PR. The ease of creating PRs with one finger leads to sloppiness.
> > >
> > > Greg
> > >
>
--
Adam Feuer <ad...@starcat.io>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Xiang Xiao <xi...@gmail.com>.
Since NuttX use Kconfig system, the simple pull/apply/compile cycle
isn't enough to catch all possible error. Actually, all my commits
pass our local automation build(four config: sim, armv7-m, armv8-m and
armv7-a) before PR sent out.
Haitao is preparing the jenkins job to run all possible config, but
the config number is huge, we need to donate several powerful severs
to ensure the precheck can finish in half hour.
Thanks
Xiang
On Tue, Jan 14, 2020 at 10:37 PM Alin Jerpelea <je...@gmail.com> wrote:
>
> Just a small checklist before pushing.!
>
> 1 *pull master*
> 2. add your patch(es)
> 3.* compile*
> 4 make distclean
> 5.* PUSH*
>
> Let's hope that we avoid having it broken again
>
> On our side as commiters, before the automation is ready, we should
> cherry-pick and build before pressing the merge button
> Can we all do that ?
>
> //Alin
>
>
> On Tue, Jan 14, 2020, 15:15 David Sidrane <Da...@nscdg.com> wrote:
>
> > The NuttX project is still misusing the tools.
> > It is not the PR. It is the process (or lack of one)
> >
> > To solve this problem:
> >
> > Build the PR on top of master BEFORE merging.
> > Do not MERGE until PR on master builds.
> >
> > David
> >
> > -----Original Message-----
> > From: Gregory Nutt [mailto:spudaneco@gmail.com]
> > Sent: Monday, January 13, 2020 6:00 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: Apache Code Relese (Was Re: Side-effects of removing (void))
> >
> >
> > > The point I'd like to make, is that I'd much rather the whole world stop
> > > turning, nothing get merged into master until we sort out the process;
> > > rather than allow anything to break master. I'd like for us to adopt a
> > > philosophy that "Nothing is worse than breaking Master." Now, that's
> > just
> > > me, I welcome counterarguments (and even flames).
> >
> > Nothing in the process is particularly different at present than in the
> > past. Several unverified PRs came in close together in time. Since
> > each broke the build and were separated over time, the build remained
> > broken for a couple weeks or more.
> >
> > There is nothing significantly different in the process from when when
> > patches were added in the same manner. Users are simply not acting
> > responsibly right now and are not verifying the changes before
> > committing them (it appears, in cases, that they are not even compiling
> > them!). That behavior has to stop.
> >
> > We were just luckier in the past and I think people were more careful
> > when they had to work up patches vs. just pushing a button to create a
> > PR. The ease of creating PRs with one finger leads to sloppiness.
> >
> > Greg
> >
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Alin Jerpelea <je...@gmail.com>.
Just a small checklist before pushing.!
1 *pull master*
2. add your patch(es)
3.* compile*
4 make distclean
5.* PUSH*
Let's hope that we avoid having it broken again
On our side as commiters, before the automation is ready, we should
cherry-pick and build before pressing the merge button
Can we all do that ?
//Alin
On Tue, Jan 14, 2020, 15:15 David Sidrane <Da...@nscdg.com> wrote:
> The NuttX project is still misusing the tools.
> It is not the PR. It is the process (or lack of one)
>
> To solve this problem:
>
> Build the PR on top of master BEFORE merging.
> Do not MERGE until PR on master builds.
>
> David
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudaneco@gmail.com]
> Sent: Monday, January 13, 2020 6:00 PM
> To: dev@nuttx.apache.org
> Subject: Re: Apache Code Relese (Was Re: Side-effects of removing (void))
>
>
> > The point I'd like to make, is that I'd much rather the whole world stop
> > turning, nothing get merged into master until we sort out the process;
> > rather than allow anything to break master. I'd like for us to adopt a
> > philosophy that "Nothing is worse than breaking Master." Now, that's
> just
> > me, I welcome counterarguments (and even flames).
>
> Nothing in the process is particularly different at present than in the
> past. Several unverified PRs came in close together in time. Since
> each broke the build and were separated over time, the build remained
> broken for a couple weeks or more.
>
> There is nothing significantly different in the process from when when
> patches were added in the same manner. Users are simply not acting
> responsibly right now and are not verifying the changes before
> committing them (it appears, in cases, that they are not even compiling
> them!). That behavior has to stop.
>
> We were just luckier in the past and I think people were more careful
> when they had to work up patches vs. just pushing a button to create a
> PR. The ease of creating PRs with one finger leads to sloppiness.
>
> Greg
>
RE: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by David Sidrane <Da...@nscdg.com>.
The NuttX project is still misusing the tools.
It is not the PR. It is the process (or lack of one)
To solve this problem:
Build the PR on top of master BEFORE merging.
Do not MERGE until PR on master builds.
David
-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Monday, January 13, 2020 6:00 PM
To: dev@nuttx.apache.org
Subject: Re: Apache Code Relese (Was Re: Side-effects of removing (void))
> The point I'd like to make, is that I'd much rather the whole world stop
> turning, nothing get merged into master until we sort out the process;
> rather than allow anything to break master. I'd like for us to adopt a
> philosophy that "Nothing is worse than breaking Master." Now, that's just
> me, I welcome counterarguments (and even flames).
Nothing in the process is particularly different at present than in the
past. Several unverified PRs came in close together in time. Since
each broke the build and were separated over time, the build remained
broken for a couple weeks or more.
There is nothing significantly different in the process from when when
patches were added in the same manner. Users are simply not acting
responsibly right now and are not verifying the changes before
committing them (it appears, in cases, that they are not even compiling
them!). That behavior has to stop.
We were just luckier in the past and I think people were more careful
when they had to work up patches vs. just pushing a button to create a
PR. The ease of creating PRs with one finger leads to sloppiness.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
> The point I'd like to make, is that I'd much rather the whole world stop
> turning, nothing get merged into master until we sort out the process;
> rather than allow anything to break master. I'd like for us to adopt a
> philosophy that "Nothing is worse than breaking Master." Now, that's just
> me, I welcome counterarguments (and even flames).
Nothing in the process is particularly different at present than in the
past. Several unverified PRs came in close together in time. Since
each broke the build and were separated over time, the build remained
broken for a couple weeks or more.
There is nothing significantly different in the process from when when
patches were added in the same manner. Users are simply not acting
responsibly right now and are not verifying the changes before
committing them (it appears, in cases, that they are not even compiling
them!). That behavior has to stop.
We were just luckier in the past and I think people were more careful
when they had to work up patches vs. just pushing a button to create a
PR. The ease of creating PRs with one finger leads to sloppiness.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by David Alessio <da...@gmail.com>.
On Mon, Jan 13, 2020 at 4:24 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> >> To Greg's point: how is it that master is broken? How did we allow any
> >> merge that hadn't yet been checked (at least to compile, if not
> function)?
> >> It seems to me that somewhere in our workflow discussion(s) we've
> >> put Descartes before the horse.
> > We need help getting that workflow document finished. Would you be able
> to
> > help with that?
>
> In particular the automated workflow. I think the basic submit and
> merge PRs is covered in detail.
>
> Haitao Liu is the person in charge of developing the automated workflow,
> but we will start off simple. He is currently setting up some Jenkins
> CI. I know that he also plans to trigger a coding standard and license
> check when the PR is submitted. But I don't know any more than that.
> There has been discussion of more targeted builds to assure that new
> changes don't break the build and discussion of hooks future
> hardware/simulator in loop testing. That is all a little vage. Without
> a specification for testing to be performed in the automated workflow,
> I'm not sure how we give guidance.
>
> Greg
>
>
I don't know HaiTao, but from the discussions here that I've read, I'm
very supportive of his approach.
The point I'd like to make, is that I'd much rather the whole world stop
turning, nothing get merged into master until we sort out the process;
rather than allow anything to break master. I'd like for us to adopt a
philosophy that "Nothing is worse than breaking Master." Now, that's just
me, I welcome counterarguments (and even flames).
-david
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Disruptive Solutions <di...@gmail.com>.
Then you have the same situation where Nuttx came from....having Greg be that only person. The only difference is people had to see the 1400+ mails also reading this “signal”.
So is this problem solved? Is there a “buddylist” where tasks are consolidated?
Ben
Verstuurd vanaf mijn iPhone
> Op 14 jan. 2020 om 06:32 heeft Justin Mclean <ju...@classsoftware.com> het volgende geschreven:
>
> Hi,
>
>> Haitao Liu is the person in charge of developing the automated workflow, but we will start off simple.
>
> Why he may be doing the work it’s probably not correct from an ASF point of view to say he’s in charge. Any contributor should be able to come along and help out, make suggestion and propose changes. The group as a whole decide what direction to go in.
>
> With a volunteer organisation assigning a task to a single person means that some of them don’t get done, it's better if the community as a whole work on things and take responsibility.
>
> Having a single person to rely on for critical infrastructure is also problematic for a number of other reasons. For instance what happens if they leave (for whatever reason) the project?
>
> Thanks,
> Justin
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Haitao Liu is the person in charge of developing the automated workflow, but we will start off simple.
Why he may be doing the work it’s probably not correct from an ASF point of view to say he’s in charge. Any contributor should be able to come along and help out, make suggestion and propose changes. The group as a whole decide what direction to go in.
With a volunteer organisation assigning a task to a single person means that some of them don’t get done, it's better if the community as a whole work on things and take responsibility.
Having a single person to rely on for critical infrastructure is also problematic for a number of other reasons. For instance what happens if they leave (for whatever reason) the project?
Thanks,
Justin
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
>> To Greg's point: how is it that master is broken? How did we allow any
>> merge that hadn't yet been checked (at least to compile, if not function)?
>> It seems to me that somewhere in our workflow discussion(s) we've
>> put Descartes before the horse.
> We need help getting that workflow document finished. Would you be able to
> help with that?
In particular the automated workflow. I think the basic submit and
merge PRs is covered in detail.
Haitao Liu is the person in charge of developing the automated workflow,
but we will start off simple. He is currently setting up some Jenkins
CI. I know that he also plans to trigger a coding standard and license
check when the PR is submitted. But I don't know any more than that.
There has been discussion of more targeted builds to assure that new
changes don't break the build and discussion of hooks future
hardware/simulator in loop testing. That is all a little vage. Without
a specification for testing to be performed in the automated workflow,
I'm not sure how we give guidance.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
>> We need help getting that workflow document finished. Would you be able to
>> help with that?
>>
>>
> Yes, I'd very much like to.
Nathan.. do you know how to give David access to Confluence? There is a
sign-up button at the upper right of the page. Is that all there is to
it? https://cwikapache.org/confluence/display/NUTTX/Nuttx
You can also get there through our shiny, new website:
https://nuttx.apache.org/
Thanks to Hans for the website; Thanks to Brennan for the DocuWiki port
to Confluence.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by David Alessio <da...@gmail.com>.
On Mon, Jan 13, 2020 at 4:03 PM Nathan Hartman <ha...@gmail.com>
wrote:
> On Mon, Jan 13, 2020 at 4:31 PM David Alessio <da...@gmail.com>
> wrote:
>
> > Forgive me, I'm just returning from a much-needed holiday break with
> family
> > and still trying to sort through 1400+ email msgs...
>
>
> Good luck with that! That's rough. More below:
>
Ha! thanks for the encouragement ;)
>
>
> > To Greg's point: how is it that master is broken? How did we allow any
> > merge that hadn't yet been checked (at least to compile, if not
> function)?
> > It seems to me that somewhere in our workflow discussion(s) we've
> > put Descartes before the horse.
>
>
> We need help getting that workflow document finished. Would you be able to
> help with that?
>
>
Yes, I'd very much like to.
> Nathan
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Jan 13, 2020 at 4:31 PM David Alessio <da...@gmail.com>
wrote:
> Forgive me, I'm just returning from a much-needed holiday break with family
> and still trying to sort through 1400+ email msgs...
Good luck with that! That's rough. More below:
> To Greg's point: how is it that master is broken? How did we allow any
> merge that hadn't yet been checked (at least to compile, if not function)?
> It seems to me that somewhere in our workflow discussion(s) we've
> put Descartes before the horse.
We need help getting that workflow document finished. Would you be able to
help with that?
Nathan
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by David Alessio <da...@gmail.com>.
Forgive me, I'm just returning from a much-needed holiday break with family
and still trying to sort through 1400+ email msgs...
To Greg's point: how is it that master is broken? How did we allow any
merge that hadn't yet been checked (at least to compile, if not function)?
It seems to me that somewhere in our workflow discussion(s) we've
put Descartes before the horse.
Confused,
-david
On Sun, Jan 12, 2020 at 4:44 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> > I have ran the build tests and do not know of any other cases like
> > this. ...
>
> That needs clarification. I have been starting the build tests everyday
> for the past weeks, but there has been no successful, complete run of
> the ARM builds in the past 3 weeks. The build has been broken every day
> for the past three weeks and the breakage appears to be getting worse,
> not better.
>
> This weekend was the due date for the 8.4 release of NuttX. That has
> now gone by. I will not be doing any further releases. That is now the
> responsibility of the PPMC. The next NuttX release will be the first
> Apache release.
>
> When should we do this first Apache release? How do we do this? Who is
> the release manager? (hint: not me) Since the breakage is coming on a
> daily basis, how/when can we get a stable enough system to even consider
> a release.
>
> I required two weeks of stable builds with no new bugs reported before a
> release. We are not ready to do a release right now. I don't think I
> have ever seen the OS so unstable as it is right now. It does not build
> correctly. There are more and more reports of old stable functionality
> that is now broken. I have no idea how to get there... at least not
> without some proper workflow definition and some qualification tools in
> place.
>
> Folks, we are destroying this OS.
>
> Greg
>
>
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Masayuki Ishikawa <ma...@gmail.com>.
Hello Greg and all,
>I think we should create a release branch and freeze nothing. Versioning
>will need to extend to 3 numbers, so the next would be 8.4.0. Every
Though I still can not catch up with all email, in my understanding the next
version would be 8.3.0.
Actually http://www.nuttx.org/Documentation/NuttX.html says the current
version is 8.2,
however I found typos in ReleaseNotes in nuttx repo which says '133nd ...
Version 8.3'.
Should I send a PR to fix these typos?
NuttX-8.2 Release Notes
------------------------
The 133nd release of NuttX, Version 8.3, was made on November 16, 2019,
and is available for download from the Bitbucket.org website. Note
that release consists of two tarballs: nuttx-8.2.tar.gz and
apps-8.2.tar.gz. These are available from:
Masayuki
2020年1月13日(月) 22:13 Gregory Nutt <sp...@gmail.com>:
>
> > I think once the workflow is complete we should froze the master and
> > keep accepting patch into dev branch. This is my point of view, I
> > don't know if we will implement it.
>
> I think we should create a release branch and freeze nothing. Versioning
> will need to extend to 3 numbers, so the next would be 8.4.0. Every
> release will have to live on a branch with multiple release candidates
> up to the released version, perhaps tagged like nuttx-8.4.0-rc1. If
> bugs are found after the release, the code could be re-released as 8.4.1
> and the bugfix merged back to main.
>
> Greg
>
>
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by "David S. Alessio" <da...@gmail.com>.
> On Jan 13, 2020, at 11:35 AM, Nathan Hartman <ha...@gmail.com> wrote:
>
> On Mon, Jan 13, 2020 at 2:12 PM David S. Alessio <da...@gmail.com>
> wrote:
>
>>
>>
>>> On Jan 13, 2020, at 5:14 AM, Gregory Nutt <sp...@gmail.com> wrote:
>>>
>>>
>>>> I think once the workflow is complete we should froze the master and
>>>> keep accepting patch into dev branch. This is my point of view, I
>>>> don't know if we will implement it.
>>>
>>> I think we should create a release branch and freeze nothing. Versioning
>> will need to extend to 3 numbers, so the next would be 8.4.0. Every
>> release will have to live on a branch with multiple release candidates up
>> to the released version, perhaps tagged like nuttx-8.4.0-rc1. If bugs are
>> found after the release, the code could be re-released as 8.4.1 and the
>> bugfix merged back to main.
>>>
>>
>> I’d like to suggest the release branches be named:
>> releases/8.4.0-rc1
>> releases/8.4.0
>> releases/8.4.1
>>
>> etc.
>>
>> As 8.4.0-r1 evolves and converges on a stable release, it can be merged
>> into 8.4.0.
>>
>> Regards,
>> -david
>>
>
> As the branches should be long lived, I suggest fewer branches by calling
> the branch "8.4.x" and then using tags (also long lived) to tag 8.4.0-rc1,
> 8.4.0, 8.4.1-rc1, etc.
That can work.
> Any bugs get fixed on master and backported to the
> branch. Changes don't get committed directly to the branch.
I see two possible scenarios:
1. a release is cut in stone and doesn’t get patched, the patched release becomes 8.4.1, for example
or
2. if a release branch can be patched, then we have to allow for a hotfix patch to be applied to that release branch. There’s a scenario where the code to be patched no longer exists on Master, it has been replaced with a different block of code...
>
> Nathan
>
>
>>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
The person that does the work should have the biggest vote. We have a
problem with too many Chiefs and not enough Indians now. Guidelines and
advice are great. Doing the job is greater.
On 1/13/2020 1:35 PM, Nathan Hartman wrote:
> On Mon, Jan 13, 2020 at 2:12 PM David S. Alessio <da...@gmail.com>
> wrote:
>
>>
>>> On Jan 13, 2020, at 5:14 AM, Gregory Nutt <sp...@gmail.com> wrote:
>>>
>>>
>>>> I think once the workflow is complete we should froze the master and
>>>> keep accepting patch into dev branch. This is my point of view, I
>>>> don't know if we will implement it.
>>> I think we should create a release branch and freeze nothing. Versioning
>> will need to extend to 3 numbers, so the next would be 8.4.0. Every
>> release will have to live on a branch with multiple release candidates up
>> to the released version, perhaps tagged like nuttx-8.4.0-rc1. If bugs are
>> found after the release, the code could be re-released as 8.4.1 and the
>> bugfix merged back to main.
>> I’d like to suggest the release branches be named:
>> releases/8.4.0-rc1
>> releases/8.4.0
>> releases/8.4.1
>>
>> etc.
>>
>> As 8.4.0-r1 evolves and converges on a stable release, it can be merged
>> into 8.4.0.
>>
>> Regards,
>> -david
>>
> As the branches should be long lived, I suggest fewer branches by calling
> the branch "8.4.x" and then using tags (also long lived) to tag 8.4.0-rc1,
> 8.4.0, 8.4.1-rc1, etc. Any bugs get fixed on master and backported to the
> branch. Changes don't get committed directly to the branch.
>
> Nathan
>
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Jan 13, 2020 at 2:12 PM David S. Alessio <da...@gmail.com>
wrote:
>
>
> > On Jan 13, 2020, at 5:14 AM, Gregory Nutt <sp...@gmail.com> wrote:
> >
> >
> >> I think once the workflow is complete we should froze the master and
> >> keep accepting patch into dev branch. This is my point of view, I
> >> don't know if we will implement it.
> >
> > I think we should create a release branch and freeze nothing. Versioning
> will need to extend to 3 numbers, so the next would be 8.4.0. Every
> release will have to live on a branch with multiple release candidates up
> to the released version, perhaps tagged like nuttx-8.4.0-rc1. If bugs are
> found after the release, the code could be re-released as 8.4.1 and the
> bugfix merged back to main.
> >
>
> I’d like to suggest the release branches be named:
> releases/8.4.0-rc1
> releases/8.4.0
> releases/8.4.1
>
> etc.
>
> As 8.4.0-r1 evolves and converges on a stable release, it can be merged
> into 8.4.0.
>
> Regards,
> -david
>
As the branches should be long lived, I suggest fewer branches by calling
the branch "8.4.x" and then using tags (also long lived) to tag 8.4.0-rc1,
8.4.0, 8.4.1-rc1, etc. Any bugs get fixed on master and backported to the
branch. Changes don't get committed directly to the branch.
Nathan
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by "David S. Alessio" <da...@gmail.com>.
> On Jan 13, 2020, at 5:14 AM, Gregory Nutt <sp...@gmail.com> wrote:
>
>
>> I think once the workflow is complete we should froze the master and
>> keep accepting patch into dev branch. This is my point of view, I
>> don't know if we will implement it.
>
> I think we should create a release branch and freeze nothing. Versioning will need to extend to 3 numbers, so the next would be 8.4.0. Every release will have to live on a branch with multiple release candidates up to the released version, perhaps tagged like nuttx-8.4.0-rc1. If bugs are found after the release, the code could be re-released as 8.4.1 and the bugfix merged back to main.
>
I’d like to suggest the release branches be named:
releases/8.4.0-rc1
releases/8.4.0
releases/8.4.1
etc.
As 8.4.0-r1 evolves and converges on a stable release, it can be merged into 8.4.0.
Regards,
-david
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
> I think once the workflow is complete we should froze the master and
> keep accepting patch into dev branch. This is my point of view, I
> don't know if we will implement it.
I think we should create a release branch and freeze nothing. Versioning
will need to extend to 3 numbers, so the next would be 8.4.0. Every
release will have to live on a branch with multiple release candidates
up to the released version, perhaps tagged like nuttx-8.4.0-rc1. If
bugs are found after the release, the code could be re-released as 8.4.1
and the bugfix merged back to main.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
>> Isn't that just a local clone of a fork of https://github.com/apache/incubator-nuttx-testing (which is currently empty other and a README).
> There is nothing to indicate this, IMO it should be a fork or a branch.
Could be anything I suppose. I created the incubator-nuttx-testing
repository a couple of days ago, but just initialized it this morning
with only a read me. I think Haitao Liu's intentions are good but it is
possible that things are little out of sync because of that. I expect a
PR on the incubator-nuttx-testing repository when he is ready.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Haitao Liu <li...@gmail.com>.
Justin,
As Greg says, it's really little out of sync : (
Before incubator-nuttx-testing repository initialized with master to fork,
I did some prepare work in my own nuttx-testing project.
Now I have forked apache/incubator-nuttx-testing, I'll switch to my own
fork to do work and then make PR to work with Apache CI.
I would take more care in future.
Justin Mclean <ju...@me.com.invalid> 于2020年1月14日周二 上午5:07写道：
> Hi,
>
> > Isn't that just a local clone of a fork of
> https://github.com/apache/incubator-nuttx-testing (which is currently
> empty other and a README).
>
> There is nothing to indicate this, IMO it should be a fork or a branch.
>
> For example if you look at [1] you can see it a fork of an ASF repo.
>
> Thanks,
> Justin
>
> 1. https://github.com/justinmclean/incubator
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Justin Mclean <ju...@me.com.INVALID>.
Hi,
> Isn't that just a local clone of a fork of https://github.com/apache/incubator-nuttx-testing (which is currently empty other and a README).
There is nothing to indicate this, IMO it should be a fork or a branch.
For example if you look at [1] you can see it a fork of an ASF repo.
Thanks,
Justin
1. https://github.com/justinmclean/incubator
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
>> Sorry late to reply here. I'm now working on Apache NuttX nightly build CI
>> setup. According to Greg's testbuild information provided,
>> now I'm preparing some CI scripts under
>> https://github.com/liuguo09/nuttx_testing to work with apache jenkins.
> Why is this work being done outside of the ASF repos? Especially when this was set up? [1]
Isn't that just a local clone of a fork of
https://github.com/apache/incubator-nuttx-testing (which is currently
empty other and a README).
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> Sorry late to reply here. I'm now working on Apache NuttX nightly build CI
> setup. According to Greg's testbuild information provided,
> now I'm preparing some CI scripts under
> https://github.com/liuguo09/nuttx_testing to work with apache jenkins.
Why is this work being done outside of the ASF repos? Especially when this was set up? [1]
Thanks,
Justin
1. https://github.com/apache/incubator-nuttx-testing
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Haitao Liu <li...@gmail.com>.
Sorry late to reply here. I'm now working on Apache NuttX nightly build CI
setup. According to Greg's testbuild information provided,
now I'm preparing some CI scripts under
https://github.com/liuguo09/nuttx_testing to work with apache jenkins. Once
done and pass tests,
I'll make pull request to apache/incubator_nuttx_testing for public review.
But now it doesn't work fully.
Abdelatif Guettouche <ab...@gmail.com> 于2020年1月13日周一
下午7:40写道：
> > What needs to be done to move closer to release?
>
> We still don't have a release process in place. We still haven't
> completed our workflow actually.
>
> It was expected to miss one release cycle, but we should've at least
> completed the requirements by now.
> It's not reasonable to consider an Apache release right now because we
> need to improve our QA process,
> which is pretty much manual at the moment.
>
> > Apparently, Haitao Liu is working on something, but that is a black
> box. We have no
> > visibility of what is happening, what is being done in detail, when it
> > will be rolled out, or how it integrates with the unfinished workflow.
>
> We need to know what Haitao Liu is working on. This will help us
> continue the workflow requirement and start the release process
> document.
>
>
>
> On Mon, Jan 13, 2020 at 10:01 AM Alan Carvalho de Assis
> <ac...@gmail.com> wrote:
> >
> > Hi Adam,
> >
> > I think once the workflow is complete we should froze the master and
> > keep accepting patch into dev branch. This is my point of view, I
> > don't know if we will implement it.
> >
> > Also we need to review all the committed patch to the master to create
> > the Changelog/Release Notes. This should be the hard part.
> >
> > BR,
> >
> > Alan
> >
> > On 1/12/20, Adam Feuer <ad...@starcat.io> wrote:
> > > What needs to be done to move closer to release?
> > >
> > > On other projects I've been on, we froze the master branch except for
> > > bugfix commits (did not merge new features), and iterated until things
> > > stabilized. Can we do that here?
> > >
> > > As to having a release manager, what's involved in that? Is there a
> role
> > > description somewhere?
> > >
> > > cheer
> > > adam
> > >
> > >
> > >
> > > On Sun, Jan 12, 2020 at 4:44 PM Gregory Nutt <sp...@gmail.com>
> wrote:
> > >
> > >>
> > >> > I have ran the build tests and do not know of any other cases like
> > >> > this. ...
> > >>
> > >> That needs clarification. I have been starting the build tests
> everyday
> > >> for the past weeks, but there has been no successful, complete run of
> > >> the ARM builds in the past 3 weeks. The build has been broken every
> day
> > >> for the past three weeks and the breakage appears to be getting worse,
> > >> not better.
> > >>
> > >> This weekend was the due date for the 8.4 release of NuttX. That has
> > >> now gone by. I will not be doing any further releases. That is now
> the
> > >> responsibility of the PPMC. The next NuttX release will be the first
> > >> Apache release.
> > >>
> > >> When should we do this first Apache release? How do we do this? Who
> is
> > >> the release manager? (hint: not me) Since the breakage is coming on
> a
> > >> daily basis, how/when can we get a stable enough system to even
> consider
> > >> a release.
> > >>
> > >> I required two weeks of stable builds with no new bugs reported
> before a
> > >> release. We are not ready to do a release right now. I don't think I
> > >> have ever seen the OS so unstable as it is right now. It does not
> build
> > >> correctly. There are more and more reports of old stable
> functionality
> > >> that is now broken. I have no idea how to get there... at least not
> > >> without some proper workflow definition and some qualification tools
> in
> > >> place.
> > >>
> > >> Folks, we are destroying this OS.
> > >>
> > >> Greg
> > >>
> > >>
> > >>
> > >
> > > --
> > > Adam Feuer <ad...@starcat.io>
> > >
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
> It was expected to miss one release cycle, but we should've at least
> completed the requirements by now.
Yes, I am not surprised that we are missing the mid-January release.
But when will be do the release? I had been releasing code every two
months, with is already a long release cycle. I don't interpret
"missing one release cycle" to mean four months without a release. I
interpret it to mean that the mid-January release will be late by some
weeks, not some months.
But with no plan in plan in place, and no one thinking about it, I am
not optimistic.
Greg
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Abdelatif Guettouche <ab...@gmail.com>.
> What needs to be done to move closer to release?
We still don't have a release process in place. We still haven't
completed our workflow actually.
It was expected to miss one release cycle, but we should've at least
completed the requirements by now.
It's not reasonable to consider an Apache release right now because we
need to improve our QA process,
which is pretty much manual at the moment.
> Apparently, Haitao Liu is working on something, but that is a black box. We have no
> visibility of what is happening, what is being done in detail, when it
> will be rolled out, or how it integrates with the unfinished workflow.
We need to know what Haitao Liu is working on. This will help us
continue the workflow requirement and start the release process
document.
On Mon, Jan 13, 2020 at 10:01 AM Alan Carvalho de Assis
<ac...@gmail.com> wrote:
>
> Hi Adam,
>
> I think once the workflow is complete we should froze the master and
> keep accepting patch into dev branch. This is my point of view, I
> don't know if we will implement it.
>
> Also we need to review all the committed patch to the master to create
> the Changelog/Release Notes. This should be the hard part.
>
> BR,
>
> Alan
>
> On 1/12/20, Adam Feuer <ad...@starcat.io> wrote:
> > What needs to be done to move closer to release?
> >
> > On other projects I've been on, we froze the master branch except for
> > bugfix commits (did not merge new features), and iterated until things
> > stabilized. Can we do that here?
> >
> > As to having a release manager, what's involved in that? Is there a role
> > description somewhere?
> >
> > cheer
> > adam
> >
> >
> >
> > On Sun, Jan 12, 2020 at 4:44 PM Gregory Nutt <sp...@gmail.com> wrote:
> >
> >>
> >> > I have ran the build tests and do not know of any other cases like
> >> > this. ...
> >>
> >> That needs clarification. I have been starting the build tests everyday
> >> for the past weeks, but there has been no successful, complete run of
> >> the ARM builds in the past 3 weeks. The build has been broken every day
> >> for the past three weeks and the breakage appears to be getting worse,
> >> not better.
> >>
> >> This weekend was the due date for the 8.4 release of NuttX. That has
> >> now gone by. I will not be doing any further releases. That is now the
> >> responsibility of the PPMC. The next NuttX release will be the first
> >> Apache release.
> >>
> >> When should we do this first Apache release? How do we do this? Who is
> >> the release manager? (hint: not me) Since the breakage is coming on a
> >> daily basis, how/when can we get a stable enough system to even consider
> >> a release.
> >>
> >> I required two weeks of stable builds with no new bugs reported before a
> >> release. We are not ready to do a release right now. I don't think I
> >> have ever seen the OS so unstable as it is right now. It does not build
> >> correctly. There are more and more reports of old stable functionality
> >> that is now broken. I have no idea how to get there... at least not
> >> without some proper workflow definition and some qualification tools in
> >> place.
> >>
> >> Folks, we are destroying this OS.
> >>
> >> Greg
> >>
> >>
> >>
> >
> > --
> > Adam Feuer <ad...@starcat.io>
> >
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Adam,
I think once the workflow is complete we should froze the master and
keep accepting patch into dev branch. This is my point of view, I
don't know if we will implement it.
Also we need to review all the committed patch to the master to create
the Changelog/Release Notes. This should be the hard part.
BR,
Alan
On 1/12/20, Adam Feuer <ad...@starcat.io> wrote:
> What needs to be done to move closer to release?
>
> On other projects I've been on, we froze the master branch except for
> bugfix commits (did not merge new features), and iterated until things
> stabilized. Can we do that here?
>
> As to having a release manager, what's involved in that? Is there a role
> description somewhere?
>
> cheer
> adam
>
>
>
> On Sun, Jan 12, 2020 at 4:44 PM Gregory Nutt <sp...@gmail.com> wrote:
>
>>
>> > I have ran the build tests and do not know of any other cases like
>> > this. ...
>>
>> That needs clarification. I have been starting the build tests everyday
>> for the past weeks, but there has been no successful, complete run of
>> the ARM builds in the past 3 weeks. The build has been broken every day
>> for the past three weeks and the breakage appears to be getting worse,
>> not better.
>>
>> This weekend was the due date for the 8.4 release of NuttX. That has
>> now gone by. I will not be doing any further releases. That is now the
>> responsibility of the PPMC. The next NuttX release will be the first
>> Apache release.
>>
>> When should we do this first Apache release? How do we do this? Who is
>> the release manager? (hint: not me) Since the breakage is coming on a
>> daily basis, how/when can we get a stable enough system to even consider
>> a release.
>>
>> I required two weeks of stable builds with no new bugs reported before a
>> release. We are not ready to do a release right now. I don't think I
>> have ever seen the OS so unstable as it is right now. It does not build
>> correctly. There are more and more reports of old stable functionality
>> that is now broken. I have no idea how to get there... at least not
>> without some proper workflow definition and some qualification tools in
>> place.
>>
>> Folks, we are destroying this OS.
>>
>> Greg
>>
>>
>>
>
> --
> Adam Feuer <ad...@starcat.io>
>
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Adam Feuer <ad...@starcat.io>.
What needs to be done to move closer to release?
On other projects I've been on, we froze the master branch except for
bugfix commits (did not merge new features), and iterated until things
stabilized. Can we do that here?
As to having a release manager, what's involved in that? Is there a role
description somewhere?
cheer
adam
On Sun, Jan 12, 2020 at 4:44 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> > I have ran the build tests and do not know of any other cases like
> > this. ...
>
> That needs clarification. I have been starting the build tests everyday
> for the past weeks, but there has been no successful, complete run of
> the ARM builds in the past 3 weeks. The build has been broken every day
> for the past three weeks and the breakage appears to be getting worse,
> not better.
>
> This weekend was the due date for the 8.4 release of NuttX. That has
> now gone by. I will not be doing any further releases. That is now the
> responsibility of the PPMC. The next NuttX release will be the first
> Apache release.
>
> When should we do this first Apache release? How do we do this? Who is
> the release manager? (hint: not me) Since the breakage is coming on a
> daily basis, how/when can we get a stable enough system to even consider
> a release.
>
> I required two weeks of stable builds with no new bugs reported before a
> release. We are not ready to do a release right now. I don't think I
> have ever seen the OS so unstable as it is right now. It does not build
> correctly. There are more and more reports of old stable functionality
> that is now broken. I have no idea how to get there... at least not
> without some proper workflow definition and some qualification tools in
> place.
>
> Folks, we are destroying this OS.
>
> Greg
>
>
>
--
Adam Feuer <ad...@starcat.io>
Apache Code Relese (Was Re: Side-effects of removing (void))
Posted by Gregory Nutt <sp...@gmail.com>.
> I have ran the build tests and do not know of any other cases like
> this. ...
That needs clarification. I have been starting the build tests everyday
for the past weeks, but there has been no successful, complete run of
the ARM builds in the past 3 weeks. The build has been broken every day
for the past three weeks and the breakage appears to be getting worse,
not better.
This weekend was the due date for the 8.4 release of NuttX. That has
now gone by. I will not be doing any further releases. That is now the
responsibility of the PPMC. The next NuttX release will be the first
Apache release.
When should we do this first Apache release? How do we do this? Who is
the release manager? (hint: not me) Since the breakage is coming on a
daily basis, how/when can we get a stable enough system to even consider
a release.
I required two weeks of stable builds with no new bugs reported before a
release. We are not ready to do a release right now. I don't think I
have ever seen the OS so unstable as it is right now. It does not build
correctly. There are more and more reports of old stable functionality
that is now broken. I have no idea how to get there... at least not
without some proper workflow definition and some qualification tools in
place.
Folks, we are destroying this OS.
Greg
Re: Side-effects of removing (void)
Posted by Gregory Nutt <sp...@gmail.com>.
> So I guess our choices are:
>
> 1. Reinstate (void) only where the warning occurs.
>
> 2. Reinstate (void) everywhere return values aren't checked. What a nightmare.
>
> 3. Change defines such as the above to static inline functions.
> Disadvantage: The inline keyword is not in the C89 standard.
I have ran the build tests and do not know of any other cases like
this. Certainly, a few more might show up but it is not an endemic
problem at the moment.
At its worst, it is only a warning.
Greg
>
Re: Side-effects of removing (void)
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Jan 7, 2020 at 5:09 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> The removal of (void) from all functions whose return value has been
> ignored has introduced several new warnings into the build test output.
> For example in lpc3_appinit(), I now see this:
>
> # define nsh_spifi_initialize() (OK)
>
> and
>
> nsh_spifi_initialize();
>
> which now generates a new warning: "warning: statement with no effect
> [-Wunused-value]"
So I guess our choices are:
1. Reinstate (void) only where the warning occurs.
2. Reinstate (void) everywhere return values aren't checked. What a nightmare.
3. Change defines such as the above to static inline functions.
Disadvantage: The inline keyword is not in the C89 standard.
Nathan