HI,
Re [1] I note it’s calling the downloads "Apache NuttX”, AFAIK there are not
Apache downloads. That page can link pre Apache downloads but it need to be
made very clear that they are not Apache releases. We‘ve had this conversation
before right?
I also note that page is also is linking to
github project boards can span multiple repos
https://help.github.com/en/github/managing-your-work-on-github/about-project-boards
On Wed, Jan 15, 2020 at 12:09 AM Gregory Nutt wrote:
>
> > The Mynewt project, for example, has many repositories. I can
> > find the page but I recall that i
Yep, it's on my to-do after you clarified what we can do for the non Apache
releases to go and fix the releases page up.
Something like this is what I was thinking:
https://daffodil.apache.org/releases/
--Brennan
On Wed, Jan 15, 2020, 12:59 AM Justin Mclean
wrote:
> HI,
>
> Re [1] I note it’s
+1 for Github issues per repo.
Repos can be cross referenced in markup.
Assignees can be assigned
labels can be assigned.
Projects (roll up across repos) can be assigned.
Milestones can be assigned.
UI is simple and effective Query by any of the above attributes.
The interfaces is present when on
On Wed, Jan 15, 2020, 10:09 AM David Sidrane
wrote:
> +1 for Github issues per repo.
>
> Repos can be cross referenced in markup.
> Assignees can be assigned
> labels can be assigned.
> Projects (roll up across repos) can be assigned.
> Milestones can be assigned.
> UI is simple and effective Que
> Where does the GitHub Projects reside?
Per repo and per Organization
> To me the core OS one was the right place, but that
seems to be off the table, I fail to see how tracking a release including
the apps (especially if the tickets are open against the apps project) is
tainting the quality of
Where does the GitHub Projects reside? What I was pushing for was a single
place not per repo. To me the core OS one was the right place, but that
seems to be off the table, I fail to see how tracking a release including
the apps (especially if the tickets are open against the apps project) is
Hi!
When I use usual file descriptor for can device:
file_open(&CANmodule->file, "/dev/can0", O_RDWR);
everything works, thread blocks if further read() and, when can message
receive, returns correct nbytes.
When I open can0 with
file_open(&file, "/dev/can0", O_RDWR);
it opens correctly and file
Oleg: do you use an extended ID or standard ID? And do you use the CAN app from
examples?
Verstuurd vanaf mijn iPhone
> Op 15 jan. 2020 om 22:02 heeft Oleg Evseev het volgende
> geschreven:
>
> Hi!
>
> When I use usual file descriptor for can device:
> file_open(&CANmodule->file, "/dev/can0
Hi!
Is it really matters? I think the issue is more about file descriptors,
file pointers and so on.
CAN is configured with extended ID. Yes, I did use CAN app from examples,
it works.
Implementation in my own app also works fine if I use file descriptor when
opened /dev/can0. In different threads
But file_read on file pointer doesn't work in the same way as read on file
descriptor, even if it is in the same thread - right after file_open!
That would be surprising because read() just calls file_read(). I would
expect the behaviors to be the same.
If there is a semaphore locking issu
Hi,
Is anyone willing to be the first release manager?
Thanks,
Justin
Hello Justin,
I cannot determine what the capabilities are that are needed and what the
impact in hours will be? And I would need guidance I have a strong passion
about Nuttx, but maybe thats not enough...
Ben
Verstuurd vanaf mijn iPhone
> Op 15 jan. 2020 om 23:52 heeft Justin Mclean het
Is anyone willing to be the first release manager?
My understanding is that the release manager does not necessarily do the
release, but is the point of contact and coordinator for releases and
needs to sign releases. Is that true?
So the job should not sound as scary as the title implie
I have been reading:
http://www.apache.org/dev/release-publishing.html
Verstuurd vanaf mijn iPhone
> Op 15 jan. 2020 om 23:52 heeft Justin Mclean het
> volgende geschreven:
>
> Hi,
>
> Is anyone willing to be the first release manager?
>
> Thanks,
> Justin
Hi,
> My understanding is that the release manager does not necessarily do the
> release, but is the point of contact and coordinator for releases and needs
> to sign releases. Is that true?
Yep that correct it more a co-ordination role to make sure everything gets
done. The release manager w
HI,
> I cannot determine what the capabilities are that are needed and what the
> impact in hours will be?
Hard to estimate hours but it should be more than a few hours week, the first
release generally take some time to get together 2 to 4 weeks is typically, but
some projects do it quicker a
Dear podling,
This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.
The board meeting is scheduled for Wed, 19 February 2020, 10:30 am PDT.
The report for your podling will for
I'm also willing to take this on or help someone else for the first
release. Can't rush the code, but it would be nice to get the other bits
in place for a release.
--Brennan
On Wed, Jan 15, 2020, 3:37 PM Justin Mclean
wrote:
> HI,
>
> > I cannot determine what the capabilities are that are ne
I would like to open a discussion for 72 hours then call a vote. The
topic is "Should we remove Windows native build support?"
What is the Windows native build? Is is a build option that supports
building NuttX in a pure Windows environment such as from a Windows IDE
or from CMD/PowerShell co
I would like to open a discussion for 72 hours then call a vote. The
topic is "Should we remove Windows native build support?"
There have been several SDKs build for Windows native in the past. One
obstacle for the Windows native build is that it requires a Windows
native port of kconfig-fr
I would like to open a discussion for 72 hours then call a vote. The
topic is "Should we remove Windows native build support?"
It occurs to me that there are really three options:
1. Remove all support for Windows native builds
2. Keep the seldom unverified Window native build, just as we d
I would like to open a discussion for 72 hours then call a vote. The
topic is "Should we remove Windows native build support?"
It occurs to me that there are really three options:
1. Remove all support for Windows native builds
2. Keep the seldom unverified Window native build, just as we
Hi,
The linux bash shell works on windows 10 (via WSL) these days. Is that an
option?
Justin
Item 2 isn't a good option: a broken build system just give the user a
very bad impression that OS self isn't workable or stable. It's better
that we fully support Windows native or remove from the list at all.
What I means the full is that all config must pass the automation
build and run the buil
25 matches
Mail list logo
