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 <xiaoxiang781...@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 <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 > > > > -- Adam Feuer <a...@starcat.io>
