WRT to this build issue, it used to work without a git repo. Disclaimer:
I responsible for the original commit, a portion of which Greg reverted
today...
This is a good opportunity to discuss a larger topic -- this is just one
instance of a class of problems that can be minimized [or even avoided]
with the proper process.
I believe that process should be based on the best practices of Bitbucket,
Github, and git. I may be stating the obvious here, but I'd like to
suggest the following few simple rules:
1. Master should always build and, to the extent possible, "just work
right."
2. all development happens on a specific development branch for one
particular feature or bug. Features are developed on a branch named
"feature/<some-cool-thing>". Bug fixes are developed on a branch named
"bugfix/<one-specific-bug>". Branches and commits must be coherent with
minimal coupling.
Note: This is important so that commits can be cherry-picked into
other branches and back-ported as hotfixes to previous releases.
3. A pull request triggers a review (review committees TBD according to
domain). A successful review might be N approvals and no rejections. In
any case, the testing, debate, and correction happens on that branch before
merge.
4. releases could be managed similarly, as a branch off of Master, i.e.
"release/9.1" (we're at 8.2.* IIRC). If a bug is then discovered in 9.1,
a branch "hotfix/some-silly-bug" would be taken off "release/9.1"
Comments? [donning flame retardant suit]
Cheers,
-david
On Fri, Dec 13, 2019 at 1:23 PM Nathan Hartman <hartman.nat...@gmail.com>
wrote:
> To add to the patch-to-merge workflow discussion, an anecdote.
>
> Earlier today I jokingly wrote "For the build system we should
> require more PMC votes than we have PMC members!!"
>
> Soon after, I grabbed the latest updates and tried to build my
> configurations and... the build was broken!
>
> I wrote:
>
> [[[
>
> Uh oh, commit 1c91aec6ae77b49608741e5aa30b8b6876017934 ("tools/ and
> fs/procfs: Simplify .version file generation") breaks the build if
> not in a git clone:
>
> $ make
> Create .version
> fatal: not a git repository (or any parent up to mount point /home/nate)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> Missing versioning information
> USAGE: tools/version.sh [-d|-h] [-b <build>] [-v <major.minor>]
> <outfile-path>
> Try 'tools/version.sh -h' for more information
> make: *** [tools/Makefile.unix:266: /home/nate/nuttx/.version] Error 1
>
> If git is not available or building a copy of NuttX which is not a git
> clone, the create version logic should degrade gracefully in a way
> that does not break the build!
>
> ]]]
>
> Thankfully, Greg fixed this at warp speed with commits
> 3e4450e2376bb99da2ed5a3f0380044ce868e564 and
> 10b8c01abfa58276f006c282e1d88481fb0a4a8e.
>
> The point is, though, that this is precisely why we need to qualify
> what gets into the system. I feel pretty strongly that we can be
> flexible with things like drivers, hacking on architectural support
> for new chips and boards, etc. The impact of bugs or incomplete code
> there will be minimal and those are easy to catch and fix. I would
> like to make it easy for contributors to get their code out there and
> to feel like there's incentive to contribute, and not to put too many
> roadblocks in the way that would become a deterrent for contributors.
>
> BUT!!
>
> The core of the OS and the build system need the highest level of
> qualification. Screwups there are really disruptive!
>
> Problems in the build system might quickly become apparent.
>
> Problems in the core OS could go undetected until intermittent
> problems that are extremely hard to trace appear in the field. Since
> NuttX goes to places like space, "in the field" might be kind of,
> slightly, REALLY far away!
>
> So we definitely need to continue discussing what process changes to
> these critical parts should undergo on their way into NuttX.
>
> Cheers,
> Nathan
>
