On Thu, Dec 19, 2019 at 10:23 PM Justin Mclean
wrote:
> Hi,
>
> > 3) The SPACEKEY is still NUTTXTEST I would like to get that moved to
> > NUTTX, but the ticket does not seem to be moving. Since the ticket was
> > about importing the wiki should I open a new once specifically for the
> >
Hi,
> 3) The SPACEKEY is still NUTTXTEST I would like to get that moved to
> NUTTX, but the ticket does not seem to be moving. Since the ticket was
> about importing the wiki should I open a new once specifically for the
> SPACEKEY change?
As long as it says "waiting for user” Infra will not
There is no longer any links to nuttx.org on the wiki, all of the content
in now attached to the space.
A few points:
0) A couple people have been helping clean some formatting and import
errors. Thank you!
1 ) All of the documentation files are now attached to the documentation
page, even if
On Thu, Dec 19, 2019 at 4:40 PM David Sidrane wrote:
> > Changes to code in MCU architectural support, board support, or features
> > in the periphery of the OS should be at the discretion of the
> > committer. Committers should use their best judgment and are
> > encouraged to discuss anything
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
On Thu, Dec 19, 2019 at 6:24 PM Gregory Nutt wrote:
> >> ] A bad build system change can cause serious problems for a lot of
people around the world. A bad change in the core OS can destroy the good
reputation of the OS.
> > Why is this the case? Users should not be using unreleased code or be
On Thu, Dec 19, 2019 at 4:42 PM Justin Mclean
wrote:
> Hi,
>
> > I don't see a bare bones report for NuttX (or any bare bones template)
> > at https://cwiki.apache.org/confluence/display/incubator/January2019,
>
> That because I copied the wrong link, sorry about that:
>
Hi,
> I don't think that the number of releases is the factor. It is time in
> people's hand. Subtle corruption of OS real time behavior is not easily
> testing. You normally have to specially instrument the software and setup a
> special test environment perhaps with a logic analyzer to
] A bad build system change can cause serious problems for a lot of people
around the world. A bad change in the core OS can destroy the good reputation
of the OS.
Why is this the case? Users should not be using unreleased code or be
encouraged to use it.. If they are one solution is to
Hi,
> I don't see a bare bones report for NuttX (or any bare bones template)
> at https://cwiki.apache.org/confluence/display/incubator/January2019,
That because I copied the wrong link, sorry about that:
https://cwiki.apache.org/confluence/display/incubator/January2020
Thanks,
Justin
This reads like a past slack discussion that ignored HW.
Is that really what an embedded system OS should do?
> Changes to code in MCU architectural support, board support, or features
> in the periphery of the OS should be at the discretion of the
> committer. Committers should use their best
+1
-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Thursday, December 19, 2019 1:20 AM
To: dev@nuttx.apache.org
Subject: Re: Contributions (PR or patches)
It would be really nice if we could get all patch series to go into PRs,
even if we don't have the
Greg, please read the first post again.
By who? Where is the vote?
-Original Message-
From: Gregory Nutt [mailto:spudan...@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
Hi,
> ] A bad build system change can cause serious problems for a lot of people
> around the world. A bad change in the core OS can destroy the good
> reputation of the OS.
Why is this the case? Users should not be using unreleased code or be
encouraged to use it.. If they are one solution
Changes that affect the build system should require three +1 binding
votes and no vetoes from PMC members
Other projects that I know of that have tried an approach like, seem to have a
lot of difficultly get those 3 +1 votes. This slows down development or worse
forms groups of people that
Hi,
>> Changes that affect the build system should require three +1 binding
>> votes and no vetoes from PMC members
Other projects that I know of that have tried an approach like, seem to have a
lot of difficultly get those 3 +1 votes. This slows down development or worse
forms groups of
On 12/19/2019 2:35 PM, Justin Mclean wrote:
Hi,
Do I understand you correctly? We can use the original google group and add a
user there with the dev@nuttx.apache.org?
Mailing list are archived / mirrored in serval places, here’s a couple:
https://lists.apache.org
Hi,
> Do I understand you correctly? We can use the original google group and add a
> user there with the dev@nuttx.apache.org?
Mailing list are archived / mirrored in serval places, here’s a couple:
https://lists.apache.org
https://markmail.org/search/
https://nabble.com (for some lists and
On Thu, Dec 19, 2019 at 8:30 AM Gregory Nutt wrote:
> On Thu, Dec 19, 2019 at 3:32 AM Sebastien Lorquet
> wrote:
>> But the endless list of complex git commands with additional options is
>> probably
>> a blocker for many other people too.
>>
>> I dont even want to read it all.
>
> You and me
It’s preferable yes. But if they can be archived and searchable that’s fine.
Often a solution is automatically sending that conversion to a mailing list or
bringing back a summary to the list.
Do I understand you correctly? We can use the original google group and add a
user there with the
On Thu, Dec 19, 2019 at 10:11 AM David Sidrane wrote:
> On 2019/12/19 14:00:36, Justin Mclean wrote:
> > > Does this need to be on only these mailing lists we have been provided by
> > > ASF?
> >
> > It’s preferable yes. But if they can be archived and searchable that’s
> > fine. Often a
On Thu, Dec 19, 2019 at 10:11 AM David Sidrane wrote:
> On 2019/12/19 14:00:36, Justin Mclean wrote:
> > It’s preferable yes. But if they can be archived and searchable that’s
> > fine. Often a solution is automatically sending that conversion to a
> > mailing list or bringing back a summary
Thank you Justin for the quick answers!
1 more below
On 2019/12/19 14:00:36, Justin Mclean wrote:
> Hi,
>
> > I would like to get some clarification on the projects degrees of freedom
> > under ASF from our mentors.
>
> As long as you follow the Apache Way you are free to do what you want.
On Thu, Dec 19, 2019 at 12:29 AM Justin Mclean wrote:
> The incubator report is in markdown format so best you copy the bare bones
> report for your project from [2] before starting to work on it.
I don't see a bare bones report for NuttX (or any bare bones template)
at
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
Hi,
> I would like to get some clarification on the projects degrees of freedom
> under ASF from our mentors.
As long as you follow the Apache Way you are free to do what you want. We have
a lot of history and over time have built up guidelines which describe what has
worked well. Sometimes
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
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
Looks really complex to me, if any contributor has to master all of this
perfectly to contribute officially.
the submodule sync with these specific options is already too much.
do you really realize all that has to be memorized just for a hat repo?
to put it another way: if you assure me
I would like to get some clarification on the projects degrees of freedom
under ASF from our mentors.
Since we are all (except a few) new to the “Apache way” I think we need
some enlightenment.
I feel it is important that we, as a group, understand what are
guidelines, rules and absolutes.
I do
Reading through the thread, it seems to me that the "git submodules"
suggestion from David sounds like a "risk".
I would like to mention that it is not: it can be seamlessly added, used
for a while, and removed later without any consequences. Creating this "hat
repo" would have exactly the same
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 wrote:
>
>
>>> I suggest that we really need to get all discussions, participation,
>>> and contributions
-1 for anything that has git submodules in it.
Didn't we try submodules at one time and it did not work out and was abandoned?
Why is this even discussed now? We can do the Apache transition with
repositories as they are today and change the
workflow or source code organization later, right?
It would be really nice if we could get all patch series to go into PRs,
even if we don't have the QA and everything setup yet. I would be happy to
automate that via something like patchwork if that is of any help.
--Brennan
On Thu, Dec 19, 2019, 12:56 AM Flavio Junqueira wrote:
> Patches
Patches through the email list are acceptable [1]. It is harder to track issues
and implement an effective workflow (e.g., running QA builds, code reviews) for
contributions via the list, but from a legal standpoint, it is acceptable.
-Flavio
[1]
Looks really complex to me, if any contributor has to master all of this
perfectly to contribute officially.
the submodule sync with these specific options is already too much.
do you really realize all that has to be memorized just for a hat repo?
to put it another way: if you assure me that
+1 Nuttx and apps should stay separate
On Sun, Dec 15, 2019 at 10:19 PM Sebastien Lorquet
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.
>
>
I agree that we should use both.
Personally I like github PR since we can do code review and automated
testing on PR
With some manual work we can also handle patches as long as they apply
clean and someone will spend the time to test them manually.
Regards
Alin
On Mon, Dec 16, 2019 at 12:56 PM
It looks good Brennan
Thanks for the effort
//Alin
On Tue, Dec 17, 2019 at 12:18 PM David Sidrane
wrote:
> Looking good! Thank you Brennan!
>
> -Original Message-
> From: Brennan Ashton [mailto:bash...@brennanashton.com]
> Sent: Tuesday, December 17, 2019 1:21 AM
> To:
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
41 matches
Mail list logo
