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 u

Re: Confirmation for subscription to NuttX mailing list

Hi, > I confirm to subscribe to NuttX Apache mailing list I’ve subscribed you. Thanks, Justin

Confirmation for subscription to NuttX mailing list

I confirm to subscribe to NuttX Apache mailing list Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this mes

Re: Project Emails

On Thu, Dec 12, 2019 at 10:05 PM Gregory Nutt 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

Re: Project Emails

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 br

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 relea

Re: Project Emails

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 app

Re: Project Emails

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 appropr

RE: Project Emails

How about sub modules? We atomically tag across both to keep the project in proper synchronization. David -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Thursday, December 12, 2019 10:55 AM To: dev@nuttx.apache.org Subject: Re: Project Emails On Thu, Dec

Re: Project Emails

+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 m

Project Repositories

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 dep

Re: Project Emails

On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt 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 th

Re: Project Emails

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

Project Emails

[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