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 >
