I have been frustrated at times by changes to master and it’s a conundrum:

- If you're developing code and base it on a stable release there's a good 
chance that by the time your own code is "done" it will be incompatible with 
latest and/or the current release.
- if you develop based on current, and rebase fairly regularly, then at least 
you keep on top of changes as they happen and are aware and/or can comment. But 
sometimes it is an unwelcome diversion, so I mostly do a new branch before a 
rebase just in case.

Once a released candidate is released, many (hopefully) people will build and 
try it and vote, or comment, accordingly?

Perhaps the main issue is the one of where should changes to the "dirty master" 
be discussed? This mailing list as a pain as so many emails get marked as junk 
and I suspect many subscribers simply don't see them. GitHub, I find, is not 
too hard to keep on top of as at least I am committing PRs, now, fairly 
regularly.

Perhaps it needs a policy decision on what the two platforms intent is?

Just my two penny's worth :)



From: Sebastien Lorquet <sebast...@lorquet.fr> 
Sent: 07 March 2023 13:12
To: dev@nuttx.apache.org
Subject: Re: Build system is broken

Hi, Do your realize how counter-intuitive this is? I would have NEVER imagined 
that V=0 is not the exact contrary of V=1! Can this silent mode be made 
optional in a config setting please? It is really a non-feature. it's just a 
fantasy to please some committer, and should have never been accepted imho. 
When I want to contribute a one liner to submit a new flash chip I get forced 
to wait 48 hours for useless automatic tests that will not even compile my new 
code, and such profound changes gets integrated immediately with almost no 
review other than an automatic build. I know it because some commits do not 
have corresponding pull requests. This gives a feeling of double standard that 
does not seem in line with the inviolables of this project. Tomek: Thanks, but 
I am not interested in workarounds that look like "here is a way to avoid 
asking why a change was made". Sebastien On 3/7/23 13:45, Nathan Hartman wrote: 
> On Tue, Mar 7, 2023 at 7:23 AM Tomek CEDRO wrote: > >> On Tue, Mar 7, 2023 at 
9:24 AM Sebastien Lorquet wrote: >>> No >>> V=1 is an entirely different thing. 
>>> I dont want to see the output mangled with tons of arm-none-eabi-gcc >>> 
command lines. >>> This stuff is another breakage >>> Sebastien > > > There is 
V=0 which gives the same output as before. > > It needs to be documented 
somehow, and in a way that people will see it, or > we will get a lot of 
complaints and questions about it after the next > release. > > Nathan > 

Reply via email to