Re: Apache Code Relese (Was Re: Side-effects of removing (void))
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 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))
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))
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 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 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))
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 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))
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))
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))
On Wed, Jan 15, 2020 at 3:01 AM Gregory Nutt 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))
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))
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))
On Wed, Jan 15, 2020 at 5:54 AM Justin Mclean 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))
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))
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))
On Wed, Jan 15, 2020 at 2:21 AM Gregory Nutt 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))
On Tue, Jan 14, 2020 at 2:01 PM Gregory Nutt 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))
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))
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))
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))
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 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 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 > 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:spudan...@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
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
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 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 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:spudan...@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))
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 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:spudan...@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))
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:spudan...@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))
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 : > > > 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))
Then you have the same situation where Nuttx came fromhaving 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 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))
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))
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 于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))
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))
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))
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))
On Mon, Jan 13, 2020 at 4:24 PM Gregory Nutt 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))
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))
On Mon, Jan 13, 2020 at 4:03 PM Nathan Hartman wrote: > On Mon, Jan 13, 2020 at 4:31 PM David Alessio > 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))
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))
On Mon, Jan 13, 2020 at 4:31 PM David Alessio 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))
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 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))
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))
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))
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))
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))
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))
> On Jan 13, 2020, at 11:35 AM, Nathan Hartman wrote: > > On Mon, Jan 13, 2020 at 2:12 PM David S. Alessio > wrote: > >> >> >>> On Jan 13, 2020, at 5:14 AM, Gregory Nutt 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))
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 wrote: On Jan 13, 2020, at 5:14 AM, Gregory Nutt 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))
On Mon, Jan 13, 2020 at 2:12 PM David S. Alessio wrote: > > > > On Jan 13, 2020, at 5:14 AM, Gregory Nutt 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))
> On Jan 13, 2020, at 5:14 AM, Gregory Nutt 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))
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))
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))
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 于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 > 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 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 > 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 > > > >
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
> 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 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 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 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 > >
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
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 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 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 >
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
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 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
