xiaoxiang781216 opened a new pull request #32: Fix stm32l4_otgfshost.c: error:
'ret' undeclared
URL: https://github.com/apache/incubator-nuttx/pull/32
result by commit 6a3c2aded683e8284e793eb3ee8793d2960ae000
Change-Id: I68ba79417d8da102da8d91c74496961aef242dd9
Signed-off-by:
acassis merged pull request #32: Fix stm32l4_otgfshost.c: error: 'ret'
undeclared
URL: https://github.com/apache/incubator-nuttx/pull/32
This is an automated message from the Apache Git Service.
To respond to the message,
Has any decision been made wrt bug tracking?
Brennan brought up Jira but many people complained about that and
preferred git issues, I think because of inertia, not based on any
logical reasons. We all love the tools that we know how to use.
But I don't think that any project wide decision
A little of topic...
@Alan PR32 is still in the repo and is ahead of master. Looks like you
didn't merge it.
BTW dev is also out of synch with master. All the PRs are getting
merged to master.
On Fri, Jan 3, 2020 at 3:12 PM Alan Carvalho de Assis wrote:
>
> Hi Nathan,
>
> On Friday, January 3,
acassis merged pull request #34: Todo
URL: https://github.com/apache/incubator-nuttx/pull/34
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above
On Thu, Jan 2, 2020 at 10:54 PM Nathan Hartman
wrote:
> On Thu, Jan 2, 2020 at 10:31 PM Gregory Nutt wrote:
>
>>
>> > Ok. I'm okay with that.
>>
>> Perhaps you could merge this for me:
>>
>> https://github.com/apache/incubator-nuttx/pull/31
>
>
Looks like Alan beat me to it.
Nathan
On Fri, Jan 3, 2020 at 2:23 AM Xiang Xiao wrote:
>
> I made this change just because the usage is inconsistent through out the
> code base. the choice to remove the cast, not to add the cast, because:
> 1.It is more easier to remove the cast by command
> 2.This change is smaller than to add the
When you say that all the issue tracker(s) were ignored (and
eventually lost anyway), that indicates a deeper problem than just
choosing an issue tracking software.
Issues will be ignored if there is no process to management them.
I think we need to first and foremost get input from our
Hi Abdelatif,
On 1/3/20, Abdelatif Guettouche wrote:
> A little of topic...
> @Alan PR32 is still in the repo and is ahead of master. Looks like you
> didn't merge it.
> BTW dev is also out of synch with master. All the PRs are getting
> merged to master.
>
I just removed the pr32 branch. I
acassis merged pull request #31: Documentation/NuttXCCodingStandard.html:
Remove requirement to decor…
URL: https://github.com/apache/incubator-nuttx/pull/31
This is an automated message from the Apache Git Service.
To
raiden00pl opened a new pull request #33: drivers/sensors/lsm6dsl.c: fix
various compiler warnings
URL: https://github.com/apache/incubator-nuttx/pull/33
This is an automated message from the Apache Git Service.
To respond
On 1/3/2020 7:46 AM, Nathan Hartman wrote:
On Fri, Jan 3, 2020 at 2:23 AM Xiang Xiao wrote:
3.It make the code a little bit clean(e.g. memcpy... vs. (void)memcpy...)
4.The return value from many function don't indicate the pass/fail(e.g.
memcpy return destination), it is reasonable to ignore
Hi Nathan,
On Friday, January 3, 2020, Nathan Hartman wrote:
> On Thu, Jan 2, 2020 at 10:54 PM Nathan Hartman
> wrote:
>
>> On Thu, Jan 2, 2020 at 10:31 PM Gregory Nutt wrote:
>>
>>>
>>> > Ok. I'm okay with that.
>>>
>>> Perhaps you could merge this for me:
>>>
>>>
BTW dev is also out of synch with master. All the PRs are getting
merged to master.
dev is no longer being used. I would like to delete it. But I want to
make sure that no-one is use 'dev' before I do so.
Trying to maintain a dev branch in synchronization is nearly
impossible. It is
On Fri, Jan 3, 2020 at 9:45 AM Gregory Nutt wrote:
> > The primary place that I keep issue is in the TODO list file in the
> > nuttx/ top-level directory. That used to be a simple way for me to
> > keep track of issues and has travel from CVS on SourceForge, to GIT on
> > sourceforge, to
davids5 commented on a change in pull request #31:
Documentation/NuttXCCodingStandard.html: Remove requirement to decor…
URL: https://github.com/apache/incubator-nuttx/pull/31#discussion_r362895441
##
File path: Documentation/NuttXCCodingStandard.html
##
@@ -2182,9
Yes. labeled "interim work flow", and should it be voted on prior to use,
(but at this point It is rather moot)
On Fri, Jan 3, 2020 at 9:26 AM Alan Carvalho de Assis
wrote:
> Hi David,
>
> Good question!
>
> I didn't create it as an ASF wiki page because it is not official and
> I think we need
Hi David,
Good question!
I didn't create it as an ASF wiki page because it is not official and
I think we need to focus on finishing the new workflow. But because we
need to avoid the chaos I decided to write it on some other place and
eventually it could be useful for other people until we get
On Fri, Jan 3, 2020 at 12:41 PM David Sidrane wrote:
>
> Yes. labeled "interim work flow", and should it be voted on prior to use,
> (but at this point It is rather moot)
>
> On Fri, Jan 3, 2020 at 9:26 AM Alan Carvalho de Assis
> wrote:
>
> > Hi David,
> >
> > Good question!
> >
> > I didn't
Hi,
> When you say that all the issue tracker(s) were ignored (and
> eventually lost anyway), that indicates a deeper problem than just
> choosing an issue tracking software.
With many people on the PPMC taking responsibility for any issues that come in
I don’t see that they would be ignored,
The interim workflow is not up for approval. The agreement is that I
will work using basically the old work flow until the new workflow is in
place. If that changes, then the agreement is null and void and I am
out of the picture. Your choice.
If any one wants to contribute to the work
With many people on the PPMC taking responsibility for any issues that come in
I don’t see that they would be ignored, unless the PPMC is not acting as a
PPMC. Other committers and contributors can alas help out and that’s one way
you grow your community and get more committers / PPMC
Hi Nathan,
On 1/3/20, Nathan Hartman wrote:
> On Fri, Jan 3, 2020 at 4:01 PM Justin Mclean
> wrote:
>> >> Re which tool to use, which one are your users likely to use. From
>> >> previous discussion I don’t think many would have used git issues, but
>> >> I’m not sure than many would be
HI,
>> Re which tool to use, which one are your users likely to use. From previous
>> discussion I don’t think many would have used git issues, but I’m not sure
>> than many would be familiar with JIRA.
>
> The majority problem reports .. well over 90% ... are recieved via email.
> Sometimes
On Fri, Jan 3, 2020 at 4:01 PM Justin Mclean wrote:
> >> Re which tool to use, which one are your users likely to use. From
> >> previous discussion I don’t think many would have used git issues, but I’m
> >> not sure than many would be familiar with JIRA.
> >
> > The majority problem reports
I spoke too soon. The NDIS gadget shows up using lsusb, but doesn't
modprobe correctly, so doesn't register as a working ethernet interface.
Here's the syslog entries from Linux:
[357068.613065] usb 1-2: new high-speed USB device number 43 using ehci-pci
> [357068.778390] usb 1-2: config 1
Maybe people should not file a bug for hardware-specific issues that
affect only their specific configuration. As you point out, it is
unlikely that anyone else will be able to fix or test such an issue.
So, for those cases, maybe we should encourage people not to file an
issue but rather to
27 matches
Mail list logo
