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 <jerpe...@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 <david.sidr...@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: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 > >
