The proposal looks good but we should also consider if we want to support LTS maintenance releases containing bugfixed backported from mainline
It is the usual case that after you release code that within one or two weeks after you release code, you discover embarrassing, gaping bugs. I solved that in the past by just distributing a patch file with the release tarballs. But I also got a lot of complaints about that; people would prefer another one off release.
I think this emphasizes the point that we need to understand and document a release requirements and procedure that is 100% consistent with Apache requirements BEFORE we begin having low level discussions on how to implement that release procedure. Alin's suggestion here could be one of those requirements.
In the short term, it is more important to focus on the workflow for accepting, qualifying, approving, and incorporating changes to the OS. Those changes will be coming soon.. within days. We can defer the first Apache NuttX release has long as we have to in order to get it right. Getting it right is more important than getting it rapidly or getting it easily. It is not the end of the world if we miss a release cycle.
When we discuss that patch-to-merge work flow, I think that the idea of a repository with nuttx/ and apps/ as sub-modules makes perfectly good sense, at least as a starting point for discussion. I personally don't think it makes any sense for starting a discussion of the release process. Perhaps it fits into the release process down the road, but it makes a bad conversation starter.
+
