Project Emails

[Gregory Nutt <sp...@gmail.com>]

[Moved to the dev list.  Was Re: Access to private email archive ].
> People should send patches to dev@.

Other projects have additional emails, often user[s] and issues, often 
many more:  https://mail-archives.apache.org/mod_mbox/

I am personally used to having a one-email-for-everything, but it looks 
like additional emails could be used if the PPMC decides to do that.

We are actually starting with a sub-project.  We probably should discuss 
that.

A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is the 
operating system proper; apps/ is a collection of applications that may 
or maynot be used with the operating system proper.  These applications 
including some key things and I think most people want to incorporate 
some subset of applications into their project.

But since the applications are NOT part of the operating system they do 
need to remain separate.  I would argue against trying to merge 
application code into the operating system.  So I think we have to 
consider these two separate releases.  We historically release them 
together as a matched pair so that the use can be user that they 
interoperate properly.

Back to emails... separating application-related discussions from core 
OS discussions might be something worth considering.  Some projects also 
have separate commits mail lists for commits to the two repositories. 
For example, the lucene project has commits, c-commits, java-commits, 
pylucene-commits, and solr-commits.  I assume that thes are all 
sub-projects.

Greg

Project Repositories

[Gregory Nutt <sp...@gmail.com>]

The current NuttX project at https://bitbucket.org/nuttx/ consists of 
five respositories.  We will need to understand how each of these 
repositories will be handled under Apache.

  * nuttx/  This is the operating system.  It is only the operating
    system.  It is complete and usable with no dependency on any other
    repsitory
  * apps/ This is a optional collection of user-space applications and
    libraries that may be used with nuttx/.  Most people use at least
    parts of the apps/ to create their full embedded application.

The above two repositories are the parts of NuttX that will be included 
as Apache NuttX and will be changed to Apache licensing. I think they 
would be sub-projects of NuttX.  The remaining three repositories are 
supporting tool repositories that are essential to supporting and using 
NuttX but have GPL licenses and cannot be released under the Apache license:

  * buildroot/ derives from the "real" buildroot at
    https://buildroot.uclibc.org/ and is used for building (mostly) GPL
    tools like GCC cross-compiler, genromfs, and kconfig-frontends for
    NuttX.
  * tools/ Contains miscellaneous sources for tools and scripts used
    with NuttX.
  * uClib++ holds and older pre-C++11 C++ library that is tailored to
    work with NuttX

There is a more contemporary C++11 library that probably should also be 
included in the discussion.  It resides at 
https://bitbucket.org/acassis/libcxx/src/master/ and is described 
here:   https://nuttx.org/doku.php?id=wiki:nshhowtos:llvm-stdcxx

These build tools must reside at some location that has close 
availability with to the Apache NuttX code.  Nothing in these GPL 
repositories is ever delivered with the NuttX releases.  There are only 
references in the documentation to these repositories as steps to 
building and installing the operating system.  Should these be 
maintained completely separately from the Apache NuttX code?  Or should 
the reside in the Apache NuttX github area?  My understanding is that 
there is a precedence for including GPL support tools in Apache github 
repositories:

  * https://www.apache.org/legal/resolved.html#build-tools
  * https://www.apache.org/legal/resolved.html#optional

We will need to revisit this in the coming weeks.

Greg

Re: Atomic git tagging (was RE: Project Emails)

[Alin Jerpelea <je...@gmail.com>]

Hi all,

I am against submodules !

If we implement submodules things will be harder on downstream projects
we guided downstream projects to integrate their own apps folder and
include our apps in their apps
http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications

Regards
Alin



On Fri, Dec 13, 2019 at 10:12 AM David Sidrane <Da...@nscdg.com>
wrote:

> Greg,
>
> I think the below steps will do a an atomic tag/branch (Branch protections
> may be needed as well)
>
> However, it exemplifies why Submodules are evil but useful.  A much simpler
> approach is 2 folder is the same project - I am aware of ALL the arguments
> -
> I agree with most of them but there are dependency on nuttx to apps from
> all
> the defconfig files and nsh)
>
> First question I would poll the community is: "How many of you do not use
> the apps folder?"
>
> ------
>
> NuttX  - is the Knot repo.
>     Apps is a sub module
>     Nuttx is a sub module
>
> origin is the remote for NuttX, apps and nuttx
>
> cd NuttX
> git checkout master
> git submodule sync --recursive && git submodule update --init --recursive
>
> git checkout -b master_imx_network_fixes
> cd nuttx
> git checkout -b master_imx_network_fixes
> cd ../apps
> git checkout -b master_imx_network_fixes
>
> cd ../nuttx
> Do all your changes.
> git add ...
> git commit  ...
> git push origin master_imx_network_fixes
>
> cd ../apps
> Do all your changes.
> git add ...
> git commit  ...
> git push origin master_imx_network_fixes
>
> cd .. (NuttX)
> git add apps nuttx
> git commit  ...
>
> git tag -a nuttx-yada -m "my version 1.4"
> git push origin nuttx-yada
> ----
>
>
> David
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudaneco@gmail.com]
> Sent: Thursday, December 12, 2019 7:05 PM
> To: dev@nuttx.apache.org
> Subject: Re: Project Emails
>
>
> > How about sub modules? We atomically tag across both to keep the project
> > in
> > proper synchronization.
>
> Some of these things are difficult to discuss at this point in time
> because we not have enough Apache knowledge and experience. What I have
> seen from following the release emails is the release will go through
> several release candidates before before a final release is made.
> Tagging releases as NuttX did in the past won't support that.  I believe
> that you would have to use branches to support a series of release
> candidates until the release is made (and perhaps even to support
> further releases on the branch for bug fixes).
>
> We can't really branch across sub-modules, can we?  I think we need to
> know much more before we could take any clear position on this.
>
> Greg
>

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

>> No, the APPSDIR is configure-able.  The default configurations all use
>> ../apps/ for APPSDIR because there are not other apps in the
>> repositores.  There have been many discussions on the old forums on how
>> to use custom applications, so I know end users actually do that.  I
>> know, for example, that many users do not use NSH (which the most
>> popular thing in apps/).
>>
>> Consider also:
>>
>> http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications
>> http://www.nuttx.org/doku.php?id=wiki:nshhowtos:custom-appsdir
> +1.
>
> Case in point: Some of my boards use NSH, others don't, depending
> on the application.
Many people people using NuttX in deeply embedded control systems with 
no possibility of a UI use NuttX with no NSH, and presumably with no 
apps/ since there is little in apps/ relevant to that kind of system.  
apps/ needs to be an option that you can use with complete flexibility 
with apps/, with contained apps, with extended apps/, with replacement 
apps/, ... basically as described in the first reference above.
>> The PPMC should
>> make all decisions based on sound reasonbing.  I personally would be
>> very opposed to anything which corrupts the clean OS architecture by
>> coupling it with any application.
> +1.
>
> It is *crucial* to keep that clean OS architecture.
>
> More below...
Absolutely.  We are all professionals.  That is a fundamental 
responsibility of being a professional.
>
> Before we can ever make a release, we first have to answer the
> question of how do changes even get committed?
>
> This is a question of project policies, which should be discussed,
> decided upon, and very importantly: documented.
>
> We shouldn't rush to come up with a policy. Rather, we should study
> the policies of other Apache.org projects to get some ideas first. For
> example, are we CTR (Commit Then Review) or RTC (Review Then Commit)?
> Do we have a mix of these two types depending on the area of the
> repository? Perhaps drivers (like SPI drivers for a particular MCU) or
> architectural support (where it is likely that only one of us has
> expertise in that particular architecture) are CTR, whereas changes
> that affect the core OS or build system require RTC with a vote and
> three +1s and no -1s to get merged. (For the build system we should
> require more PMC votes than we have PMC members!! Just kidding.)

I wonder if it would be of value to have some dialog with Mynewt.  They 
deal with releases from multiple GIT repositories and have a lot in 
common with NuttX.  In my contacts with Mynewt folk in the past, they 
were friendly and helpful.

We do have to come up with some basic workflow for how a patch that 
appears in dev@nuttx.apache.org gets reviewed, verified, approved and 
incorporated onto the master.  The time when we need that basic workflow 
is days away.  We need to agree on the sequence of events that must 
occur (not on tools and implementations of those events).  It is likely 
that we might have to have a sub-team managing the workflow manually 
until we are fully tooled up.

Greg

Re: Atomic git tagging (was RE: Project Emails)

[David Alessio <da...@gmail.com>]

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 <ha...@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
>

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

> ....  I am trying to get everything moved to apache.org, bit at a 
> time. Slack channels are shutting down, the word is slowly getting out 
> in the Google group.  ..

I have removed the Slack application from most of my machines.  I have 
deactivated the accounts of all Inactive members.  I will no longer 
login -- except to deactivate members as they become inactive.  When all 
members are dactivated, I will delete the Slack altogether.  People just 
have to stop using it and I will assure that it goes aware in its entirety.

Greg

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

Hi, Justin
>> No, AFAIK, no SGA's have been filed. The wording here is https://incubator.apache.org/guides/ip_clearance.html is unclear to me under "Establishing Provenance".  Contributor in this case refers to copyright holders, I assume?
> This only applies to code you are giving to the ASF (it’s actually not a transfer of copyright but permission to use), so this would only be the code owned by the NuttX project. It doesn’t include 3rd party code in the repo. The headers on those files owned by NuttX will change, but the headers of any 3rd party code will need to stay the same.
>
> I think the first step if for you to fill out a SGA and will discuss on legal discuss if anything else is needed. I think because you were the only person with commit right and the headers with your copyright that’s all that would be required.
>
>> There are several files that will require corporate CLAs, I think, since the copy right holders are businesses like Sony or Pinecone.
> That’s not required as they are 3rd party files and belong to someone else. CCLA in general are not needed by the ASF, they are there because some companies require them for their employees to be able to work on OS software.

The signed SGA has been sent to secretary@apache.org.  I do you yet have 
any confirmation.  So I think we can arrange the transfer of the 
repositories as soon as possible.

Thanks for all of your help.  We really need it!

Greg

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

I will send the SGA this weekend.

Also I am going to try to decouple better.  It is not because I am 
trying be the BDFL, it is just in my nature to "mother hen" software 
projects.  I will be detach and I will let the PPMP form itself with 
less influence from me.  I will try to continue to help when I can, but 
the PPMC must sink or swim based on the focus and motivation of the 
people who wanted to be members, not on my urging.

If I am successful, you will hear less from me on these topics.

Greg

On 12/13/2019 5:17 PM, Justin Mclean wrote:
> Hi,
>
>> No, AFAIK, no SGA's have been filed. The wording here is https://incubator.apache.org/guides/ip_clearance.html is unclear to me under "Establishing Provenance".  Contributor in this case refers to copyright holders, I assume?
> This only applies to code you are giving to the ASF (it’s actually not a transfer of copyright but permission to use), so this would only be the code owned by the NuttX project. It doesn’t include 3rd party code in the repo. The headers on those files owned by NuttX will change, but the headers of any 3rd party code will need to stay the same.
>
> I think the first step if for you to fill out a SGA and will discuss on legal discuss if anything else is needed. I think because you were the only person with commit right and the headers with your copyright that’s all that would be required.
>
>> There are several files that will require corporate CLAs, I think, since the copy right holders are businesses like Sony or Pinecone.
> That’s not required as they are 3rd party files and belong to someone else. CCLA in general are not needed by the ASF, they are there because some companies require them for their employees to be able to work on OS software.
>
> Thanks,
> Justin

Re: Atomic git tagging (was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> No, AFAIK, no SGA's have been filed. The wording here is https://incubator.apache.org/guides/ip_clearance.html is unclear to me under "Establishing Provenance".  Contributor in this case refers to copyright holders, I assume? 

This only applies to code you are giving to the ASF (it’s actually not a transfer of copyright but permission to use), so this would only be the code owned by the NuttX project. It doesn’t include 3rd party code in the repo. The headers on those files owned by NuttX will change, but the headers of any 3rd party code will need to stay the same.

I think the first step if for you to fill out a SGA and will discuss on legal discuss if anything else is needed. I think because you were the only person with commit right and the headers with your copyright that’s all that would be required.

> There are several files that will require corporate CLAs, I think, since the copy right holders are businesses like Sony or Pinecone.

That’s not required as they are 3rd party files and belong to someone else. CCLA in general are not needed by the ASF, they are there because some companies require them for their employees to be able to work on OS software.

Thanks,
Justin

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

> Has the SGA been filled in and submitted?

No, AFAIK, no SGA's have been filed. The wording here is 
https://incubator.apache.org/guides/ip_clearance.html is unclear to me 
under "Establishing Provenance".  Contributor in this case refers to 
copyright holders, I assume?  The BSD headers list only copy right 
holders and authors.  I suppose on the copyright holder can contribute 
software.  Often there are numerous authors but only one copyright holder.

Well, the good news is this will slow things down quite a bit so next is 
probably not the week that the Tsunami hits.

There are several files that will require corporate CLAs, I think, since 
the copy right holders are businesses like Sony or Pinecone.

The PPMC needs to take this up and coordinate it.

Re: Atomic git tagging (was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> that we are playing chicken with putting critical processes in place and making the transition to Apache repositories.  That transition supposed to happen next week, right?

It happens when the PPMC decided for it to happen. But first the SGA needs to de accepted [1] and then we may need to talk about if we need ICLA from the contributors or not.[2]

Has the SGA been filled in and submitted?

Thanks,
Justin

1, https://www.apache.org/licenses/contributor-agreements.html#grants
2. https://www.apache.org/licenses/contributor-agreements.html#clas

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

>> So where in Apache is an appropriate place to put shared documents, the Apache public equivalent of my shared drive?  I have been trying to scare people into action on this workflow here for days now, but I guess this a brave group or just completely blind to what is coming.
> Best place is confluence. We would need to set up a space for NuttX but that’s easily done. Do you want me to go ahead and do that?

I'll let others decide.  My Google drive is not appropriate, I know 
that.  It might be more practical in a short term, however, since we 
don't know how to use Confluence yet.  I am trying to get everything 
moved to apache.org, bit at a time.  Slack channels are shutting down, 
the word is slowly getting out in the Google group.  In this case, I am 
concerned that we are playing chicken with putting critical processes in 
place and making the transition to Apache repositories.  That transition 
supposed to happen next week, right?

We made an agreement just before the proposal went up for vote that we 
would make the transition from the Bitbucket to Apache repositories 
"knife edge":  The Bitbucket repositories will stop being updated as 
synchronously as possible to the time when the Apache repositories go 
online.

What do you all recommend?  I will concur with whatever is the general 
feeling in the PPMC.

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

> What is coming is 10-30 patches per day.  When the Apache repositories 
> are set up.  I will cease processing all changes. All PRs and patches 
> that I receive will be forwarded to this email.  It is then the PPMC's 
> total responsibility to deal with them.  Drop the ball for one day and 
> you will be behind 10-30 commits.  Drop the ball for ten more days and 
> you will be 100-300 commits behind.  That will be a crisis!
There are slower times and busier times for commits.  It changes like 
the seasons.  It changes during the week as well.  Fridays, Saturdays, 
and Sundays are usually lighter.  Today, Friday the 13th, there were 
only 8 commits.

Re: Confluence/Repos (Was Atomic git tagging)

[Alan Carvalho de Assis <ac...@gmail.com>]

Hi Justin,

On 12/14/19, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Hehe.. nutty-apps :-D
>
> That was autocorrect I think. It was [1] so I didn’t mistype it when
> creating it this time :-)
>

Great! Thank you!

BR,

Alan

Re: Confluence/Repos (Was Atomic git tagging)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Hehe.. nutty-apps :-D

That was autocorrect I think. It was [1] so I didn’t mistype it when creating it this time :-)

Thanks,
Justin

1. https://gitbox.apache.org/repos/asf?p=incubator-nuttx-apps.git

Re: Confluence/Repos (Was Atomic git tagging)

[Gregory Nutt <sp...@gmail.com>]

>> Justin, do you mind to rename it from app to apps ?
> I’ve created an incubator-nutty-apps one and asked Infra how to remove the other one.

Hehe.. nutty-apps :-D

There are some pretty crazy applications in there.

G

Re: Confluence/Repos (Was Atomic git tagging)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Justin, do you mind to rename it from app to apps ?

I’ve created an incubator-nutty-apps one and asked Infra how to remove the other one.

Thanks,
Justin

Re: Confluence/Repos (Was Atomic git tagging)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> There would be less confusion if the repository were called apps instead of nuttx-apps[s], but it appears the the project name on the front of the repository is an Apache convention.

Yes as is incubating for incubating projects.

> In the release tarballs, the names have been apps-x.y/ and nuttx-x.y/ where x.y is the major.minor version number. 

You can number your releases however you want. The name does need to number “incubating” and it’s a good idea to also put “apache” in there so something like apache-nuttx-incubating-x.y.tag,gz and apache-nuttx-apps-incubating-x.y.tag,gz would be fine. But other variations on this would also be fine.

Thanks,
Justin

Re: Confluence/Repos (Was Atomic git tagging)

[Gregory Nutt <sp...@gmail.com>]

Alan,
> Hmm, I think it could create some confusion because all docs and even the
> build system expects to find the applications directory at ../apps/
>
> Justin, do you mind to rename it from app to apps ?

You note that the git clone with no argument will create nuttx-app/ (or 
nuttx-apps/), right?  So there is going to be confusion in any event.  
nuttx-apps/ is a little closer to expectations, however.  The directory 
name can, of course, be set to anything you like in the 'git clone' command.

There would be less confusion if the repository were called apps instead 
of nuttx-apps[s], but it appears the the project name on the front of 
the repository is an Apache convention.

In the release tarballs, the names have been apps-x.y/ and nuttx-x.y/ 
where x.y is the major.minor version number.  I suppose that those are 
not affected (other than we will likely need to go to an x.y.z version 
number where z is the revision number.

Greg

Re: Confluence/Repos (Was Atomic git tagging)

[Alan Carvalho de Assis <ac...@gmail.com>]

Hi Greg and Justin,

On Saturday, December 14, 2019, Gregory Nutt <sp...@gmail.com> wrote:
>
>> So I created:
>> https://gitbox.apache.org/repos/asf/incubator-nuttx.git
>> https://gitbox.apache.org/repos/asf/incubator-nuttx-app.git
>
> At nit:  Historically, the directory is call apps/ not app/. That is the
way it is referred to in all of the documentation of and the consciousness
of NuttX users.
>
> But I am flexible if others are too.
>

Hmm, I think it could create some confusion because all docs and even the
build system expects to find the applications directory at ../apps/

Justin, do you mind to rename it from app to apps ?

BR,

Alan

Re: Confluence/Repos (Was Atomic git tagging)

[Gregory Nutt <sp...@gmail.com>]

> So I created:
> https://gitbox.apache.org/repos/asf/incubator-nuttx.git
> https://gitbox.apache.org/repos/asf/incubator-nuttx-app.git

At nit:  Historically, the directory is call apps/ not app/. That is the 
way it is referred to in all of the documentation of and the 
consciousness of NuttX users.

But I am flexible if others are too.

Re: Confluence/Repos (Was Atomic git tagging)

[Justin Mclean <ju...@classsoftware.com>]

HI,

I created the repos there was an issue in that it didn’t like incubator-nuttx-nuttx, which I guess is a bit silly.

So I created:
https://gitbox.apache.org/repos/asf/incubator-nuttx.git
https://gitbox.apache.org/repos/asf/incubator-nuttx-app.git

You can see the mirror repos here:
https://github.com/apache?q=nuttx

You can use the above GitHub clones or you can use the Apache ones, everything syncs up between them.

To use the GitHub one you need to sync your accounts as described here [1]

Thanks,
Justin

1. https://gitbox.apache.org

Re: Confluence/Repos (Was Atomic git tagging)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I am unsure of the terminology "report".  I assume this is the name of the GIT repository?  For consistency, the name of the repositories should be apps/ and nuttx/.

Sorry I meant repos. I’ll go ahead and create them.

Thanks,
Justin

Re: Confluence/Repos (Was Atomic git tagging)

[Gregory Nutt <sp...@gmail.com>]

>> This doesn't seem to accept my LDAP credentials.  Actually, it does.  I can log in but I don't seem to have authority to do anything.
> Fixed - any NuttX committer will now be able to add/edit/comment on pages. Opening it wider than that may attract spam.

Thanks!

I had to limit the DocuWiki's too.  Not because I wanted to, but because 
it was constantly under attack.  One day I noticed 37 thousand+ new 
subscribers in a span a a couple of weeks.

>
>> Now that the SGA has been filed we can also request that the repositories be set up well, correct?
> They are easy to set up, from the other documentation it seems we want two reports right. what should they be called?

I am unsure of the terminology "report".  I assume this is the name of 
the GIT repository?  For consistency, the name of the repositories 
should be apps/ and nuttx/.

Greg

Re: Confluence/Repos (Was Atomic git tagging)

[Justin Mclean <ju...@me.com.INVALID>]

Hi,

> This doesn't seem to accept my LDAP credentials.  Actually, it does.  I can log in but I don't seem to have authority to do anything.

Fixed - any NuttX committer will now be able to add/edit/comment on pages. Opening it wider than that may attract spam.

> Now that the SGA has been filed we can also request that the repositories be set up well, correct?

They are easy to set up, from the other documentation it seems we want two reports right. what should they be called?

Thanks,
Justin

Confluence/Repos (Was Atomic git tagging)

[Gregory Nutt <sp...@gmail.com>]

Hi, Justin
> I really don’t think there will be any issues doing both in parallel so I’ve created a confluence space here:
> https://cwiki.apache.org/confluence/display/NUTTX

Thanks!

This doesn't seem to accept my LDAP credentials.  Actually, it does.  I 
can log in but I don't seem to have authority to do anything.

>
>> I have heard that the INFRA team has some special kung-fu for importing Wikis into confluence.  I hope they can handle an old DocuWiki site.
>>
>> Is there any way that could be expedited?
> For thing like this the process is to raise an JIRA ticket for Infra. I’ve just raised one here:
> https://issues.apache.org/jira/browse/INFRA-19570

Thanks again!

Now that the SGA has been filed we can also request that the 
repositories be set up well, correct?

Greg

Re: Atomic git tagging (was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

I really don’t think there will be any issues doing both in parallel so I’ve created a confluence space here:
https://cwiki.apache.org/confluence/display/NUTTX

> I have heard that the INFRA team has some special kung-fu for importing Wikis into confluence.  I hope they can handle an old DocuWiki site.
> 
> Is there any way that could be expedited?

For thing like this the process is to raise an JIRA ticket for Infra. I’ve just raised one here:
https://issues.apache.org/jira/browse/INFRA-19570

Thanks,
Justin

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

>> Is there reason for me to be concerned?
> Unfortunately, yes.  As much as I like Confluence, if not properly
> organized and managed, it can quickly grow into an unnavigable mess.
> I suppose it's like anything else we do, it requires a process and
> disciplined maintainer...

Then I think we should not use Confluence until we have the Wiki 
framework in place.

I have heard that the INFRA team has some special kung-fu for importing 
Wikis into confluence.  I hope they can handle an old DocuWiki site.

Is there any way that could be expedited?

Re: Atomic git tagging (was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> The original plan was to integrate the existing DocuWiki at nuttx.org to Confluence.  If we begin using Confluence in an ad hoc way then I have some concern that it will interfere with the clean port of the existing Wiki.  

I don’t think there will be any issues along those lines, any new pages can be moved into an any imported space.

Thanks,
Justin

Re: Atomic git tagging (was RE: Project Emails)

[Alan Carvalho de Assis <ac...@gmail.com>]

On 12/13/19, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Do you know know project which did it in the past?
>
> Not from DocuWiki that I’m aware of. A search of the entire ASF mail
> archives [1] didn’t find anything.
>
> Let wait until Infra get back to us - that may take a day or two.
>

Right, thank you again.

BR,

Alan

Re: Atomic git tagging (was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Do you know know project which did it in the past?

Not from DocuWiki that I’m aware of. A search of the entire ASF mail archives [1] didn’t find anything.

Let wait until Infra get back to us - that may take a day or two.

Thanks,
Justin

1. https://lists.apache.org/search.html

Re: Atomic git tagging (was RE: Project Emails)

[Alan Carvalho de Assis <ac...@gmail.com>]

Hi Justin,

On 12/13/19, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> It appears there are a converter from DocuWiki to Confluence:
>> https://community.atlassian.com/t5/Answers-Developer-Questions/how-to-import-quot-dokuwiki-quot-to-confluence/qaq-p/526583
>
> Yep I noted that on the JIRA.
>

How could help in this process to migrate the DocuWiki?

Do you know know project which did it in the past?

BR,

Alan

Re: Atomic git tagging (was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> It appears there are a converter from DocuWiki to Confluence:
> https://community.atlassian.com/t5/Answers-Developer-Questions/how-to-import-quot-dokuwiki-quot-to-confluence/qaq-p/526583

Yep I noted that on the JIRA.

Thanks,
Justin

Re: Atomic git tagging (was RE: Project Emails)

[Alan Carvalho de Assis <ac...@gmail.com>]

Hi Greg,

On 12/13/19, Gregory Nutt <sp...@gmail.com> wrote:
>
>> Absolutely, Confluence would be great -- it'd be good place to create
>> live
>> documents and tutorials that could evolve along with the code base...
>
> The original plan was to integrate the existing DocuWiki at nuttx.org to
> Confluence.  If we begin using Confluence in an ad hoc way then I have
> some concern that it will interfere with the clean port of the existing
> Wiki.  My hope is that we could have a clean Confluence website.  Is
> there reason for me to be concerned?
>

It appears there are a converter from DocuWiki to Confluence:

https://community.atlassian.com/t5/Answers-Developer-Questions/how-to-import-quot-dokuwiki-quot-to-confluence/qaq-p/526583

BR,

Alan

Re: Atomic git tagging (was RE: Project Emails)

[David Alessio <da...@gmail.com>]

> Is there reason for me to be concerned?

Unfortunately, yes.  As much as I like Confluence, if not properly
organized and managed, it can quickly grow into an unnavigable mess.
I suppose it's like anything else we do, it requires a process and
disciplined maintainer...

On Fri, Dec 13, 2019 at 2:42 PM Gregory Nutt <sp...@gmail.com> wrote:

>
> > Absolutely, Confluence would be great -- it'd be good place to create
> live
> > documents and tutorials that could evolve along with the code base...
>
> The original plan was to integrate the existing DocuWiki at nuttx.org to
> Confluence.  If we begin using Confluence in an ad hoc way then I have
> some concern that it will interfere with the clean port of the existing
> Wiki.  My hope is that we could have a clean Confluence website.  Is
> there reason for me to be concerned?
>
>
>
>

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

> Absolutely, Confluence would be great -- it'd be good place to create live
> documents and tutorials that could evolve along with the code base...

The original plan was to integrate the existing DocuWiki at nuttx.org to 
Confluence.  If we begin using Confluence in an ad hoc way then I have 
some concern that it will interfere with the clean port of the existing 
Wiki.  My hope is that we could have a clean Confluence website.  Is 
there reason for me to be concerned?

Re: Atomic git tagging (was RE: Project Emails)

[David Alessio <da...@gmail.com>]

Absolutely, Confluence would be great -- it'd be good place to create live
documents and tutorials that could evolve along with the code base...

On Fri, Dec 13, 2019 at 2:02 PM Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> > So where in Apache is an appropriate place to put shared documents, the
> Apache public equivalent of my shared drive?  I have been trying to scare
> people into action on this workflow here for days now, but I guess this a
> brave group or just completely blind to what is coming.
>
> Best place is confluence. We would need to set up a space for NuttX but
> that’s easily done. Do you want me to go ahead and do that?
>
> Thanks,
> Justin

Re: Atomic git tagging (was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> So where in Apache is an appropriate place to put shared documents, the Apache public equivalent of my shared drive?  I have been trying to scare people into action on this workflow here for days now, but I guess this a brave group or just completely blind to what is coming.

Best place is confluence. We would need to set up a space for NuttX but that’s easily done. Do you want me to go ahead and do that?

Thanks,
Justin

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

> So we definitely need to continue discussing what process changes to
> these critical parts should undergo on their way into NuttX.

I think "continue" is generous.  I don't think the discussion has 
successfully even gotten off the ground.  It is a looming crisis that is 
going hit us like a Tsunami in just a handful of days. And there seems 
to be no focused concern.  There is feeble attempt at  work flow 
document on a shared Google drive (I just gave you access).   But there 
seems to be no interest.  It is in terrible shape, it is incomplete and 
unread-able.  has had only three edits since it was created two weeks 
ago.  Clearly a lack of interest in digging in.

So where in Apache is an appropriate place to put shared documents, the 
Apache public equivalent of my shared drive?  I have been trying to 
scare people into action on this workflow here for days now, but I guess 
this a brave group or just completely blind to what is coming.

What is coming is 10-30 patches per day.  When the Apache repositories 
are set up.  I will cease processing all changes. All PRs and patches 
that I receive will be forwarded to this email.  It is then the PPMC's 
total responsibility to deal with them.  Drop the ball for one day and 
you will be behind 10-30 commits.  Drop the ball for ten more days and 
you will be 100-300 commits behind.  That will be a crisis!

Re: Atomic git tagging (was RE: Project Emails)

[Nathan Hartman <ha...@gmail.com>]

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

Re: Atomic git tagging (was RE: Project Emails)

[Nathan Hartman <ha...@gmail.com>]

On Fri, Dec 13, 2019 at 8:05 AM Gregory Nutt <sp...@gmail.com> wrote:
> Let's fully understand the release process before proposing a solution.

+1.

More below...

> No, the APPSDIR is configure-able.  The default configurations all use
> ../apps/ for APPSDIR because there are not other apps in the
> repositores.  There have been many discussions on the old forums on how
> to use custom applications, so I know end users actually do that.  I
> know, for example, that many users do not use NSH (which the most
> popular thing in apps/).
>
> Consider also:
>
> http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications
> http://www.nuttx.org/doku.php?id=wiki:nshhowtos:custom-appsdir

+1.

Case in point: Some of my boards use NSH, others don't, depending
on the application.

More below...

> The PPMC should
> make all decisions based on sound reasonbing.  I personally would be
> very opposed to anything which corrupts the clean OS architecture by
> coupling it with any application.

+1.

It is *crucial* to keep that clean OS architecture.

More below...

> This discussion is really all about a proposed shortcut for a release (a
> release that we do not yet understand).  I would say two things about
> that:  (1) I don't think we should take shortcuts to releases (and we
> certainly should not sacrifice the integrity of the OS just to use a
> shortcut) -- that is one of the "enemies" of good system design.  And
> (2) we really need to understand and document the release procedure
> BEFORE we begin proposing solutions, especially solutions that have long
> reachable negative impacts.
>
> Tradeoffs are a necessary part of getting things done and all trade-offs
> involve compromising between two things, one that you like and one that
> you dont like.  We may have to compromise things to achieve what we
> want, but now is not the time.  But remember that "premature
> optimization is the root of all evil."

Before we can ever make a release, we first have to answer the
question of how do changes even get committed?

This is a question of project policies, which should be discussed,
decided upon, and very importantly: documented.

We shouldn't rush to come up with a policy. Rather, we should study
the policies of other Apache.org projects to get some ideas first. For
example, are we CTR (Commit Then Review) or RTC (Review Then Commit)?
Do we have a mix of these two types depending on the area of the
repository? Perhaps drivers (like SPI drivers for a particular MCU) or
architectural support (where it is likely that only one of us has
expertise in that particular architecture) are CTR, whereas changes
that affect the core OS or build system require RTC with a vote and
three +1s and no -1s to get merged. (For the build system we should
require more PMC votes than we have PMC members!! Just kidding.)

As an example, here's the document from my other Apache.org project:

https://subversion.apache.org/docs/community-guide/

That document covers coding conventions, release procedures, voting on
changes, and many other policy issues.

We can use that as a template of what needs to be covered in our
document.

Nathan

Re: Atomic git tagging (was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

> I think the below steps will do a an atomic tag/branch (Branch protections
> may be needed as well)
Let's fully understand the release process before proposing a solution.  
That sounds like a disaster.
> However, it exemplifies why Submodules are evil but useful.  A much simpler
> approach is 2 folder is the same project - I am aware of ALL the arguments -
> I agree with most of them but there are dependency on nuttx to apps from all
> the defconfig files and nsh)

No, the APPSDIR is configure-able.  The default configurations all use 
../apps/ for APPSDIR because there are not other apps in the 
repositores.  There have been many discussions on the old forums on how 
to use custom applications, so I know end users actually do that.  I 
know, for example, that many users do not use NSH (which the most 
popular thing in apps/).

Consider also:

http://www.nuttx.org/doku.php?id=wiki:nshhowtos:external-applications
http://www.nuttx.org/doku.php?id=wiki:nshhowtos:custom-appsdir

I don't think simple is particularly strong argument.

> First question I would poll the community is: "How many of you do not use
> the apps folder?"

This is an internal architectural decision and I don't think it is an 
issue that involves any kind of community vote.  That is how we got 
Trump, we get a dictatorship of the uninformed majority. The PPMC should 
make all decisions based on sound reasonbing.  I personally would be 
very opposed to anything which corrupts the clean OS architecture by 
coupling it with any application.

This discussion is really all about a proposed shortcut for a release (a 
release that we do not yet understand).  I would say two things about 
that:  (1) I don't think we should take shortcuts to releases (and we 
certainly should not sacrifice the integrity of the OS just to use a 
shortcut) -- that is one of the "enemies" of good system design.  And 
(2) we really need to understand and document the release procedure 
BEFORE we begin proposing solutions, especially solutions that have long 
reachable negative impacts.

Tradeoffs are a necessary part of getting things done and all trade-offs 
involve compromising between two things, one that you like and one that 
you dont like.  We may have to compromise things to achieve what we 
want, but now is not the time.  But remember that "premature 
optimization is the root of all evil."

Atomic git tagging (was RE: Project Emails)

[David Sidrane <Da...@nscdg.com>]

Greg,

I think the below steps will do a an atomic tag/branch (Branch protections
may be needed as well)

However, it exemplifies why Submodules are evil but useful.  A much simpler
approach is 2 folder is the same project - I am aware of ALL the arguments -
I agree with most of them but there are dependency on nuttx to apps from all
the defconfig files and nsh)

First question I would poll the community is: "How many of you do not use
the apps folder?"

------

NuttX  - is the Knot repo.
    Apps is a sub module
    Nuttx is a sub module

origin is the remote for NuttX, apps and nuttx

cd NuttX
git checkout master
git submodule sync --recursive && git submodule update --init --recursive

git checkout -b master_imx_network_fixes
cd nuttx
git checkout -b master_imx_network_fixes
cd ../apps
git checkout -b master_imx_network_fixes

cd ../nuttx
Do all your changes.
git add ...
git commit  ...
git push origin master_imx_network_fixes

cd ../apps
Do all your changes.
git add ...
git commit  ...
git push origin master_imx_network_fixes

cd .. (NuttX)
git add apps nuttx
git commit  ...

git tag -a nuttx-yada -m "my version 1.4"
git push origin nuttx-yada
----


David

-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Thursday, December 12, 2019 7:05 PM
To: dev@nuttx.apache.org
Subject: Re: Project Emails


> How about sub modules? We atomically tag across both to keep the project
> in
> proper synchronization.

Some of these things are difficult to discuss at this point in time
because we not have enough Apache knowledge and experience. What I have
seen from following the release emails is the release will go through
several release candidates before before a final release is made.
Tagging releases as NuttX did in the past won't support that.  I believe
that you would have to use branches to support a series of release
candidates until the release is made (and perhaps even to support
further releases on the branch for bug fixes).

We can't really branch across sub-modules, can we?  I think we need to
know much more before we could take any clear position on this.

Greg

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Does Apache have any requirements that we must follow for how releases are made available?

Yes they need to be placed in the ASF mirrors. Note that the word release has a particular meaning at the ASF and must contain only source code and voted on by a PMC.

Here’s the full release and distribution policies. [1][2]

Short version is that they need to be placed on http://www.apache.org/dist/incubator, the release candidates can go on https://dist.apache.org/repos/dist/dev/incubator/. Once voted on by the PPMC and the IPMC you can use svn mv to move a RC to the release area.

Thanks,
Justin

1. http://www.apache.org/legal/release-policy.html
2. https://www.apache.org/dev/release-distribution.html

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

> 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. ...

I think that the first question we would need to answer in a discussion 
of the releases is, "What is the form of the release that is seen by the 
user?"  In the past, that was:

 1. Two separate versioned tarballs, one for apps/ and one for nutts/
 2. ReleaseNotes, and
 3. A tagged repository.

The creation of the tarballs was done by the script tools/zipme.sh.  
That script requires the version number and the commit  UID at the HEAD 
of the nuttx/ repository (addressing Justin's concern with tags).  It 
generates the tarballs and also a .version file in the root.  That 
.version file contains the versioning information in various formats as 
well as the UID. The .version file is directly include-able by scripts 
and Makefile fragments.  At build time, the .version is used to create 
an include/nuttx/version.h header file making the version information 
available to C and C++ code as well.

Releases were posted on SourceForge and Bitbucket download areas.  
Release announcements were made in the NuttX Google group and in the 
LinkedIn NuttX group.

That is what the world is used to.  Do you see things that should 
change?  Probably the repository tags would become branches and 
locations where releases are available would change.  But other than 
that, is there any reason why anything else change? Certainly, there 
should be no artificial coupling been apps/ and nuttx/.  I believe that 
those must stay independent.

Does Apache have any requirements that we must follow for how releases 
are made available?

Greg

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

> 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.


+

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Justin Mclean <ju...@me.com.INVALID>]

Hi,

> I think this is of secondary importance, but certainly any change to the documented use of NuttX should a factor that is taken into consideration.  Ideally, the only user impact should be the URL used with the 'git clone' (or download).

In general you want to point users to official releases and not unreleased code. [1]

Thanks,
Justin

1. http://www.apache.org/legal/release-policy.html#publication

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Justin Mclean <ju...@me.com.INVALID>]

Hi 

We can have as many repos as we need and they are easy to set up via ASF self-serve. [1]

Thanks,
Justin

1. https://selfserve.apache.org

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Xiang Xiao <xi...@gmail.com>]

I think we can keep apps and nuttx as two separate gits, mynewt even has dozen:
https://gitbox.apache.org/repos/asf?s=mynewt
It's enough to just change tag to branch for incoperating the potential bugfix.

Thanks
Xiang

On Fri, Dec 13, 2019 at 9:53 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> Another thing to consider with the form of the release is that there an
> many, many documents, Wikis, READMEs, HowTos, blogs, and videos
> describing how to get started with NuttX.  They all begin either 'git
> clone' apps/ and nuttx/ (or download the tarballs). Changing that means
> breaking a lot of things.
>
> I think this is of secondary importance, but certainly any change to the
> documented use of NuttX should a factor that is taken into
> consideration.  Ideally, the only user impact should be the URL used
> with the 'git clone' (or download).
>
>

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I did create a #nuttx channel in the ASF slack: https://app.slack.com/client/, but it has been recommended that we not use that Slack for communication either.

It’s fine to talk there but decisions need to be made on the mailing list. Real time communication excludes people who may not be in your time zone or may not be able to work on the project during their $dayjob, asynchronous communication (i.e email) is preferred as it allows everyone a chance to be involved. There are other good reason as well previously discussed.

While I'm a user of Slack and follow about 20 slack workspaces I'm not going to closely follow any NuttX slack channel, following the mailing list is all that should be needed o know what is going on in a project.

Thanks,
Justin

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

>> Why would you want to shut down your slack space? Some projects use a 
>> slack space and even the ASF has one: the-asf.slack.com
> I was asked to shut down all NuttX project communications that are not 
> publicly visible.  I have done that.  It was a slow gradual phase out, 
> described in the Google group.

I did create a #nuttx channel in the ASF slack: 
https://app.slack.com/client/, but it has been recommended that we not 
use that Slack for communication either.

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

HI,

> By who? Where is the vote?

Conversation in Apache projects need to be in the open, so I’m not sure that a vote in needed to shut down something not controlled by the Apache project that privately run.

Thanks,
Justin

RE: Workflow and Release strategy Proposal (Was RE: Project Emails)

[David Sidrane <Da...@nscdg.com>]

By who? Where is the vote?

-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Thursday, December 19, 2019 5:45 AM
To: dev@nuttx.apache.org
Subject: Re: Workflow and Release strategy Proposal (Was RE: Project Emails)


> Why would you want to shut down your slack space? Some projects use a
> slack space and even the ASF has one: the-asf.slack.com
I was asked to shut down all NuttX project communications that are not
publicly visible.  I have done that.  It was a slow gradual phase out,
described in the Google group.

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

> Why would you want to shut down your slack space? Some projects use a slack space and even the ASF has one: the-asf.slack.com
I was asked to shut down all NuttX project communications that are not 
publicly visible.  I have done that.  It was a slow gradual phase out, 
described in the Google group.

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Flavio Junqueira <fp...@apache.org>]

Greg,

Why would you want to shut down your slack space? Some projects use a slack space and even the ASF has one: the-asf.slack.com

-Flavio

> On 14 Dec 2019, at 00:46, Gregory Nutt <sp...@gmail.com> wrote:
> 
> 
>>> I suggest that we really need to get all discussions, participation,
>>> and contributions "under one roof" so to speak, at
>>> dev@nuttx.apache.org. I think the Slack, the Google Group, the
>>> LinkedIn Group, and any other forums that fragment participants,
>>> should wind up soon. Whenever we reply to a message there, we should
>>> remind people that those forums are deprecated and that they should
>>> join dev@nuttx.apache.org.
>>> 
>> I think at least the LinkedIn group is not in this category of
>> removing users from the mailing list, quite the opposite. The LinkedIn
>> group goal is to advertise and show projects and products using NuttX.
>> Many people discovered NuttX thanks our announcements there. There is
>> not a discussion group in the Linkedin, but only a showcase for NuttX.
> 
> The LinkedIn group really is a different creature.  It has thousands of subscribers and close to no participation.  Alan is essentially the only poster there.
> 
> I am willing to shut down the Slack right now, at this moment. Every time I proposed doing that, people balk because there might be something of importance there.  There might be, but it would be in a closed channel or a person-to-person conversation.  I think it should go now, but I need support and concurrence to take that step.
> 
> Just speak the words and it is gone.
> 

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

>> I suggest that we really need to get all discussions, participation,
>> and contributions "under one roof" so to speak, at
>> dev@nuttx.apache.org. I think the Slack, the Google Group, the
>> LinkedIn Group, and any other forums that fragment participants,
>> should wind up soon. Whenever we reply to a message there, we should
>> remind people that those forums are deprecated and that they should
>> join dev@nuttx.apache.org.
>>
> I think at least the LinkedIn group is not in this category of
> removing users from the mailing list, quite the opposite. The LinkedIn
> group goal is to advertise and show projects and products using NuttX.
> Many people discovered NuttX thanks our announcements there. There is
> not a discussion group in the Linkedin, but only a showcase for NuttX.

The LinkedIn group really is a different creature.  It has thousands of 
subscribers and close to no participation.  Alan is essentially the only 
poster there.

I am willing to shut down the Slack right now, at this moment. Every 
time I proposed doing that, people balk because there might be something 
of importance there.  There might be, but it would be in a closed 
channel or a person-to-person conversation.  I think it should go now, 
but I need support and concurrence to take that step.

Just speak the words and it is gone.

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Nathan Hartman <ha...@gmail.com>]

On Fri, Dec 13, 2019 at 6:52 PM Alan Carvalho de Assis <ac...@gmail.com>
wrote:

> HI Justin,
>
> On 12/13/19, Justin Mclean <ju...@classsoftware.com> wrote:
> > Hi,
> >
> > I would have no issue with keeping the linked in group, especially it
> used
> > like that. It would be best to share ownership of it to all the PPMC.
> Many
> > project have twitter accounts. facebook pages, stack overflow accounts
> etc
> > etc. What important is the he main discussion happens on this mailing
> list
> > and that the decisions are made here.
> >
>
> I agree! Currently only I and Greg are the Managers of the group, but
> we can extent it to all PPMC interested to advertise about this great
> project.
>
> So, if someone here want to help us in the LinkedIn group, please just
> inform your LinkedIn account and we will add you as Manager as well


Okay, I understand better the purpose of the LinkedIn and I agree that it
should stay.

I'm all in favor of advertising the existence of NuttX far and wide.

By the same token, can we keep the Google Group and use it the same way,
I.e., post a copy of all announcements there but if anyone new comes along
and asks questions we should point them to the official discussion channel?

Nathan

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Alan Carvalho de Assis <ac...@gmail.com>]

HI Justin,

On 12/13/19, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> I would have no issue with keeping the linked in group, especially it used
> like that. It would be best to share ownership of it to all the PPMC. Many
> project have twitter accounts. facebook pages, stack overflow accounts etc
> etc. What important is the he main discussion happens on this mailing list
> and that the decisions are made here.
>

I agree! Currently only I and Greg are the Managers of the group, but
we can extent it to all PPMC interested to advertise about this great
project.

So, if someone here want to help us in the LinkedIn group, please just
inform your LinkedIn account and we will add you as Manager as well.

BR,

Alan

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

I would have no issue with keeping the linked in group, especially it used like that. It would be best to share ownership of it to all the PPMC. Many project have twitter accounts. facebook pages, stack overflow accounts etc etc. What important is the he main discussion happens on this mailing list and that the decisions are made here.

Thanks,
Justin

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Alan Carvalho de Assis <ac...@gmail.com>]

Hi Nathan,

On 12/13/19, Nathan Hartman <ha...@gmail.com> wrote:
> On Fri, Dec 13, 2019 at 8:53 AM Gregory Nutt <sp...@gmail.com> wrote:
>
>> Another thing to consider with the form of the release is that there an
>> many, many documents, Wikis, READMEs, HowTos, blogs, and videos
>> describing how to get started with NuttX.  They all begin either 'git
>> clone' apps/ and nuttx/ (or download the tarballs). Changing that means
>> breaking a lot of things.
>
>
> There is no reason to change that.
>
> Releases should be in the form of tarballs and those who wish to hack
> on NuttX or be on the bleeding edge can clone the git repos. Nothing
> changes there except the URL where you download those things (and the
> fact that the PMC members will digitally sign the release tarballs
> with our PGP/GPG keys). To minimize confusion, all the places that
> have until now hosted NuttX tarballs and git repos should have a big
> "WE HAVE MOVED!" message with our new address.
>
> Not directly related but Greg mentioned Google and LinkedIn:
>
> I suggest that we really need to get all discussions, participation,
> and contributions "under one roof" so to speak, at
> dev@nuttx.apache.org. I think the Slack, the Google Group, the
> LinkedIn Group, and any other forums that fragment participants,
> should wind up soon. Whenever we reply to a message there, we should
> remind people that those forums are deprecated and that they should
> join dev@nuttx.apache.org.
>

I think at least the LinkedIn group is not in this category of
removing users from the mailing list, quite the opposite. The LinkedIn
group goal is to advertise and show projects and products using NuttX.
Many people discovered NuttX thanks our announcements there. There is
not a discussion group in the Linkedin, but only a showcase for NuttX.

We can turn it off is all people here decide to do so, but I think we
will shoot the foot if we do it.

Just my two cents.

BR,

Alan

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Nathan Hartman <ha...@gmail.com>]

On Fri, Dec 13, 2019 at 8:53 AM Gregory Nutt <sp...@gmail.com> wrote:

> Another thing to consider with the form of the release is that there an
> many, many documents, Wikis, READMEs, HowTos, blogs, and videos
> describing how to get started with NuttX.  They all begin either 'git
> clone' apps/ and nuttx/ (or download the tarballs). Changing that means
> breaking a lot of things.


There is no reason to change that.

Releases should be in the form of tarballs and those who wish to hack
on NuttX or be on the bleeding edge can clone the git repos. Nothing
changes there except the URL where you download those things (and the
fact that the PMC members will digitally sign the release tarballs
with our PGP/GPG keys). To minimize confusion, all the places that
have until now hosted NuttX tarballs and git repos should have a big
"WE HAVE MOVED!" message with our new address.

Not directly related but Greg mentioned Google and LinkedIn:

I suggest that we really need to get all discussions, participation,
and contributions "under one roof" so to speak, at
dev@nuttx.apache.org. I think the Slack, the Google Group, the
LinkedIn Group, and any other forums that fragment participants,
should wind up soon. Whenever we reply to a message there, we should
remind people that those forums are deprecated and that they should
join dev@nuttx.apache.org.

If there is any valuable information on the Slack or LinkedIn that is
of use to NuttX and shouldn't be lost, I suggest asking whoever posted
it if they'll kindly copy and paste into an email to dev@, to bring it
under the one roof and also to open it up to anyone who wants to get
involved in the project.

Nathan

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Gregory Nutt <sp...@gmail.com>]

Another thing to consider with the form of the release is that there an 
many, many documents, Wikis, READMEs, HowTos, blogs, and videos 
describing how to get started with NuttX.  They all begin either 'git 
clone' apps/ and nuttx/ (or download the tarballs). Changing that means 
breaking a lot of things.

I think this is of secondary importance, but certainly any change to the 
documented use of NuttX should a factor that is taken into 
consideration.  Ideally, the only user impact should be the URL used 
with the 'git clone' (or download).

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Alin Jerpelea <je...@gmail.com>]

The proposal looks good but we should also consider if we want to support
LTS maintenance releases containing bugfixed backported from mainline

Regards
Alin


On Fri, Dec 13, 2019, 09:27 David Sidrane <Da...@nscdg.com> wrote:

> Precisely! We cut a branch as a Release Candidate. nuttx-MM.mm.rr-rcnn.
> During the release cycle it can have back ports from master if a new
> feature
> or bug fix is found it is added if deemed necessary to the release.
>
> Workflow Proposal
>
> I would ask that we adopt a workflow similar to PX4. [1] - see page 16.  Or
> parts of it that work for us.
>
> All development would be done on branches and only squashed atomic commits
> would be done to master. (Think constantly working bisect on master)
>
> Branches can be rebased - to reduce noise until review [1] see page 17
>
> All commit message would have context. [1] - see page 16 (Think emails
> subject tells me what happed, Filter out noise)
>
> Regards,
>
> David
>
> [1] https://drive.google.com/open?id=1XHaNB3nTarjPL-CzO9CpZTl1NgX_kpqY
>
>
> -----Original Message-----
> From: spudaneco [mailto:spudaneco@gmail.com]
> Sent: Thursday, December 12, 2019 9:16 PM
> To: dev@nuttx.apache.org
> Subject: Re: Project Emails
>
> Sent from Samsung tablet.
> I think we should use release branches, unless we want to lock downthe repo
> against all changes for the duration of the release prep ->release
> candidate -> testing -> debating -> voting cycle, which couldtake a non
> trivial amount of time.You could carry on business as usual on a temporary
> branch, but that feels awkward.
>

Workflow and Release strategy Proposal (Was RE: Project Emails)

[David Sidrane <Da...@nscdg.com>]

Precisely! We cut a branch as a Release Candidate. nuttx-MM.mm.rr-rcnn.
During the release cycle it can have back ports from master if a new feature
or bug fix is found it is added if deemed necessary to the release.

Workflow Proposal

I would ask that we adopt a workflow similar to PX4. [1] - see page 16.  Or
parts of it that work for us.

All development would be done on branches and only squashed atomic commits
would be done to master. (Think constantly working bisect on master)

Branches can be rebased - to reduce noise until review [1] see page 17

All commit message would have context. [1] - see page 16 (Think emails
subject tells me what happed, Filter out noise)

Regards,

David

[1] https://drive.google.com/open?id=1XHaNB3nTarjPL-CzO9CpZTl1NgX_kpqY


-----Original Message-----
From: spudaneco [mailto:spudaneco@gmail.com]
Sent: Thursday, December 12, 2019 9:16 PM
To: dev@nuttx.apache.org
Subject: Re: Project Emails

Sent from Samsung tablet.
I think we should use release branches, unless we want to lock downthe repo
against all changes for the duration of the release prep ->release
candidate -> testing -> debating -> voting cycle, which couldtake a non
trivial amount of time.You could carry on business as usual on a temporary
branch, but that feels awkward.

Re: Project Emails

[spudaneco <sp...@gmail.com>]

Sent from Samsung tablet.
I think we should use release branches, unless we want to lock downthe repo against all changes for the duration of the release prep ->release candidate -> testing -> debating -> voting cycle, which couldtake a non trivial amount of time.You could carry on business as usual on a temporary branch, but that feels awkward.

Re: Project Emails

[Nathan Hartman <ha...@gmail.com>]

On Thu, Dec 12, 2019 at 10:05 PM Gregory Nutt <sp...@gmail.com> wrote:
> Some of these things are difficult to discuss at this point in time
> because we not have enough Apache knowledge and experience. What I have
> seen from following the release emails is the release will go through
> several release candidates before before a final release is made.
> Tagging releases as NuttX did in the past won't support that.  I believe
> that you would have to use branches to support a series of release
> candidates until the release is made (and perhaps even to support
> further releases on the branch for bug fixes).

I think we should use release branches, unless we want to lock down
the repo against all changes for the duration of the release prep ->
release candidate -> testing -> debating -> voting cycle, which could
take a non trivial amount of time.

With a release branch, normal development can continue to be merged to
master during this time.

Any release-blocking bugs found during release testing get fixed on
master and then merged (just those commits) to the release branch.

Re: Project Emails

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>  Tagging releases as NuttX did in the past won't support that.  I believe that you would have to use branches to support a series of release candidates until the release is made (and perhaps even to support further releases on the branch for bug fixes).

Most projects use release branches that I know of, but some use tags.

> We can't really branch across sub-modules, can we?  I think we need to know much more before we could take any clear position on this.

You could use the same tag on different repo, but as tag are mutable you would need to include the commit hash for both repos.

Thanks,
Justin

Re: Project Emails

[Gregory Nutt <sp...@gmail.com>]

> How about sub modules? We atomically tag across both to keep the project in
> proper synchronization.

Some of these things are difficult to discuss at this point in time 
because we not have enough Apache knowledge and experience. What I have 
seen from following the release emails is the release will go through 
several release candidates before before a final release is made.  
Tagging releases as NuttX did in the past won't support that.  I believe 
that you would have to use branches to support a series of release 
candidates until the release is made (and perhaps even to support 
further releases on the branch for bug fixes).

We can't really branch across sub-modules, can we?  I think we need to 
know much more before we could take any clear position on this.

Greg

Re: Project Emails

[Gregory Nutt <sp...@gmail.com>]

> I think submodules are a good way to go. That would leave us with 3 repos
> as the core Apache NuttX. One for 'nuttx' which, is Greg suggests, should
> always be exclusively the OS. One for 'apps'. And one for "linking" them
> together, and for providing other NuttX infrastructure that may not be
> appropriate in the core OS repo.

And the purpose of the third repositories with two submodules is... 
what?  We discussed this configuration before as a device to support 
automated testing which requires both both an operating system and test 
applications.  Is that the intent here?  That might be a good testing 
solution, but is probably premature to discuss here.

DavidS was referring to something else.  I think a David was referring 
to a way to make releases from a single repo.  I would think the first 
and most straightforward solution for that would be two synchronized 
releases from two separate repositories. Keeping the releases as loosely 
coupled as possible, I think, would provide the greatest flexibility to 
end-users.  The loss of flexibility would have to be balanced against 
the level of effort.  Would the purpose of such a third repository just 
for releases be an attempt to reduce effort?

What is the final form of the release?  In the past it was two tagged 
repositories and two tarballs with the same versioning. What would be 
the form of the release in this case be?

Re: Project Emails

[Alin Jerpelea <je...@gmail.com>]

+1 Nuttx and apps should stay separate


On Sun, Dec 15, 2019 at 10:19 PM Sebastien Lorquet <se...@lorquet.fr>
wrote:

> hello,
>
> I am not favorable personally with submodules. They are a pain to keep
> in sync across multiple remotes and branches.
>
> This was used in the past in NuttX, and it was aborted.
>
> Sebastien
>
> On 12/13/19 3:28 AM, Anthony Merlino wrote:
> > I think submodules are a good way to go. That would leave us with 3 repos
> > as the core Apache NuttX. One for 'nuttx' which, is Greg suggests, should
> > always be exclusively the OS. One for 'apps'. And one for "linking" them
> > together, and for providing other NuttX infrastructure that may not be
> > appropriate in the core OS repo.
> >
> > [image: photo]
> > *Anthony Merlino*
> > CTO & Co-founder, Verge Aero
> > (609)-319-1399
> >
> >
> >
> > On Thu, Dec 12, 2019 at 8:17 PM David Sidrane <Da...@nscdg.com>
> > wrote:
> >
> >> How about sub modules? We atomically tag across both to keep the
> project in
> >> proper synchronization.
> >>
> >> David
> >>
> >> -----Original Message-----
> >> From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> >> Sent: Thursday, December 12, 2019 10:55 AM
> >> To: dev@nuttx.apache.org
> >> Subject: Re: Project Emails
> >>
> >> On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt <sp...@gmail.com>
> wrote:
> >>> A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is
> the
> >>> operating system proper; apps/ is a collection of applications that may
> >>> or maynot be used with the operating system proper.  These applications
> >>> including some key things and I think most people want to incorporate
> >>> some subset of applications into their project.
> >>>
> >>> But since the applications are NOT part of the operating system they do
> >>> need to remain separate.  I would argue against trying to merge
> >>> application code into the operating system.  So I think we have to
> >>> consider these two separate releases.  We historically release them
> >>> together as a matched pair so that the use can be user that they
> >>> interoperate properly.
> >> +1 : I agree that nuttx and apps should stay separate.
> >>
> >> That begs the question, are we going to have two separate Git
> >> repositories? Because Git lacks support for multiple projects in one
> >> repository. (There's nothing in Git that prevents you from trying, but
> >> Git does not have the features that make the "monorepo"/"megarepo"
> >> pattern work; e.g., it does not have sparse/partial working copies or
> >> clones. Trying to combine nuttx and apps into one repository would
> >> force everyone to clone a lot of content they may not need/want and
> >> which may complicate building the RTOS with only their custom
> >> applications.)
> >>
> >> Nathan
> >>
>

Re: Project Emails

[Sebastien Lorquet <se...@lorquet.fr>]

hello,

I am not favorable personally with submodules. They are a pain to keep 
in sync across multiple remotes and branches.

This was used in the past in NuttX, and it was aborted.

Sebastien

On 12/13/19 3:28 AM, Anthony Merlino wrote:
> I think submodules are a good way to go. That would leave us with 3 repos
> as the core Apache NuttX. One for 'nuttx' which, is Greg suggests, should
> always be exclusively the OS. One for 'apps'. And one for "linking" them
> together, and for providing other NuttX infrastructure that may not be
> appropriate in the core OS repo.
>
> [image: photo]
> *Anthony Merlino*
> CTO & Co-founder, Verge Aero
> (609)-319-1399
>
>
>
> On Thu, Dec 12, 2019 at 8:17 PM David Sidrane <Da...@nscdg.com>
> wrote:
>
>> How about sub modules? We atomically tag across both to keep the project in
>> proper synchronization.
>>
>> David
>>
>> -----Original Message-----
>> From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
>> Sent: Thursday, December 12, 2019 10:55 AM
>> To: dev@nuttx.apache.org
>> Subject: Re: Project Emails
>>
>> On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt <sp...@gmail.com> wrote:
>>> A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is the
>>> operating system proper; apps/ is a collection of applications that may
>>> or maynot be used with the operating system proper.  These applications
>>> including some key things and I think most people want to incorporate
>>> some subset of applications into their project.
>>>
>>> But since the applications are NOT part of the operating system they do
>>> need to remain separate.  I would argue against trying to merge
>>> application code into the operating system.  So I think we have to
>>> consider these two separate releases.  We historically release them
>>> together as a matched pair so that the use can be user that they
>>> interoperate properly.
>> +1 : I agree that nuttx and apps should stay separate.
>>
>> That begs the question, are we going to have two separate Git
>> repositories? Because Git lacks support for multiple projects in one
>> repository. (There's nothing in Git that prevents you from trying, but
>> Git does not have the features that make the "monorepo"/"megarepo"
>> pattern work; e.g., it does not have sparse/partial working copies or
>> clones. Trying to combine nuttx and apps into one repository would
>> force everyone to clone a lot of content they may not need/want and
>> which may complicate building the RTOS with only their custom
>> applications.)
>>
>> Nathan
>>

Re: Project Emails

[Anthony Merlino <an...@vergeaero.com>]

I think submodules are a good way to go. That would leave us with 3 repos
as the core Apache NuttX. One for 'nuttx' which, is Greg suggests, should
always be exclusively the OS. One for 'apps'. And one for "linking" them
together, and for providing other NuttX infrastructure that may not be
appropriate in the core OS repo.

[image: photo]
*Anthony Merlino*
CTO & Co-founder, Verge Aero
(609)-319-1399



On Thu, Dec 12, 2019 at 8:17 PM David Sidrane <Da...@nscdg.com>
wrote:

> How about sub modules? We atomically tag across both to keep the project in
> proper synchronization.
>
> David
>
> -----Original Message-----
> From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> Sent: Thursday, December 12, 2019 10:55 AM
> To: dev@nuttx.apache.org
> Subject: Re: Project Emails
>
> On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt <sp...@gmail.com> wrote:
> > A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is the
> > operating system proper; apps/ is a collection of applications that may
> > or maynot be used with the operating system proper.  These applications
> > including some key things and I think most people want to incorporate
> > some subset of applications into their project.
> >
> > But since the applications are NOT part of the operating system they do
> > need to remain separate.  I would argue against trying to merge
> > application code into the operating system.  So I think we have to
> > consider these two separate releases.  We historically release them
> > together as a matched pair so that the use can be user that they
> > interoperate properly.
>
> +1 : I agree that nuttx and apps should stay separate.
>
> That begs the question, are we going to have two separate Git
> repositories? Because Git lacks support for multiple projects in one
> repository. (There's nothing in Git that prevents you from trying, but
> Git does not have the features that make the "monorepo"/"megarepo"
> pattern work; e.g., it does not have sparse/partial working copies or
> clones. Trying to combine nuttx and apps into one repository would
> force everyone to clone a lot of content they may not need/want and
> which may complicate building the RTOS with only their custom
> applications.)
>
> Nathan
>

RE: Project Emails

[David Sidrane <Da...@nscdg.com>]

How about sub modules? We atomically tag across both to keep the project in
proper synchronization.

David

-----Original Message-----
From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
Sent: Thursday, December 12, 2019 10:55 AM
To: dev@nuttx.apache.org
Subject: Re: Project Emails

On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt <sp...@gmail.com> wrote:
> A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is the
> operating system proper; apps/ is a collection of applications that may
> or maynot be used with the operating system proper.  These applications
> including some key things and I think most people want to incorporate
> some subset of applications into their project.
>
> But since the applications are NOT part of the operating system they do
> need to remain separate.  I would argue against trying to merge
> application code into the operating system.  So I think we have to
> consider these two separate releases.  We historically release them
> together as a matched pair so that the use can be user that they
> interoperate properly.

+1 : I agree that nuttx and apps should stay separate.

That begs the question, are we going to have two separate Git
repositories? Because Git lacks support for multiple projects in one
repository. (There's nothing in Git that prevents you from trying, but
Git does not have the features that make the "monorepo"/"megarepo"
pattern work; e.g., it does not have sparse/partial working copies or
clones. Trying to combine nuttx and apps into one repository would
force everyone to clone a lot of content they may not need/want and
which may complicate building the RTOS with only their custom
applications.)

Nathan

Re: Project Emails

[Gregory Nutt <sp...@gmail.com>]

> +1 : I agree that nuttx and apps should stay separate.
>
> That begs the question, are we going to have two separate Git
> repositories? Because Git lacks support for multiple projects in one
> repository. (There's nothing in Git that prevents you from trying, but
> Git does not have the features that make the "monorepo"/"megarepo"
> pattern work; e.g., it does not have sparse/partial working copies or
> clones. Trying to combine nuttx and apps into one repository would
> force everyone to clone a lot of content they may not need/want and
> which may complicate building the RTOS with only their custom
> applications.)

It would also force an unnatural coupling between two independent bodies 
of software that should not be coupled.  Merging the two repositories 
into one would also be a technical feat since they have 133 necessary 
tags with common names, but no common commits. The also share some 
history since apps was a part of the nuttx/ repository many years ago 
before I realized that was a mistake and separated them.  I still 
consider merging the repositories a mistake.

It is not possible to have a NuttX team like: 
https://github.com/nuttx?tab=following  Anthony Merlino created that 
team as an experiment last month, but it has not been maintained or updated.

Greg

Re: Project Emails

[Nathan Hartman <ha...@gmail.com>]

On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt <sp...@gmail.com> wrote:
> A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is the
> operating system proper; apps/ is a collection of applications that may
> or maynot be used with the operating system proper.  These applications
> including some key things and I think most people want to incorporate
> some subset of applications into their project.
>
> But since the applications are NOT part of the operating system they do
> need to remain separate.  I would argue against trying to merge
> application code into the operating system.  So I think we have to
> consider these two separate releases.  We historically release them
> together as a matched pair so that the use can be user that they
> interoperate properly.

+1 : I agree that nuttx and apps should stay separate.

That begs the question, are we going to have two separate Git
repositories? Because Git lacks support for multiple projects in one
repository. (There's nothing in Git that prevents you from trying, but
Git does not have the features that make the "monorepo"/"megarepo"
pattern work; e.g., it does not have sparse/partial working copies or
clones. Trying to combine nuttx and apps into one repository would
force everyone to clone a lot of content they may not need/want and
which may complicate building the RTOS with only their custom
applications.)

Nathan

Re: Project Emails

[Flavio Junqueira <fp...@apache.org>]

Hi Greg,

On the email lists, the mentor's guide suggest that we create dev@, commits@, and private@, also recommending that we add user@ later if needed:

https://incubator.apache.org/guides/mentor.html#request_mailing_lists <https://incubator.apache.org/guides/mentor.html#request_mailing_lists>

We are following the guidelines, but there is some flexibility to it.

-Flavio

> On 12 Dec 2019, at 19:36, Gregory Nutt <sp...@gmail.com> wrote:
> 
> [Moved to the dev list.  Was Re: Access to private email archive ].
>> People should send patches to dev@.
> 
> Other projects have additional emails, often user[s] and issues, often many more:  https://mail-archives.apache.org/mod_mbox/
> 
> I am personally used to having a one-email-for-everything, but it looks like additional emails could be used if the PPMC decides to do that.
> 
> We are actually starting with a sub-project.  We probably should discuss that.
> 
> A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is the operating system proper; apps/ is a collection of applications that may or maynot be used with the operating system proper.  These applications including some key things and I think most people want to incorporate some subset of applications into their project.
> 
> But since the applications are NOT part of the operating system they do need to remain separate.  I would argue against trying to merge application code into the operating system.  So I think we have to consider these two separate releases.  We historically release them together as a matched pair so that the use can be user that they interoperate properly.
> 
> Back to emails... separating application-related discussions from core OS discussions might be something worth considering.  Some projects also have separate commits mail lists for commits to the two repositories. For example, the lucene project has commits, c-commits, java-commits, pylucene-commits, and solr-commits.  I assume that thes are all sub-projects.
> 
> Greg
> 
> 
>