Nice!
I think _Every PR_ needs a description do begin to be a responsible and
professional contribution. The small extra level of effort will keep the
team informed and provide the documentation for the release process. We
should not have to reverse engineer intent to get the one line "what" and
"
I only mentioned macOS because one of the mentors was using it the
last time, I guess what's important is to have instructions that start
from a fresh installation of any OS and end with a usable workstation,
I'm sure there are plenty for Linux.
> Re: the release notes, maybe we can start using a
On Thu, Jun 4, 2020 at 2:07 AM Brennan Ashton wrote:
> So Nathan has done an awesome job getting a start on the release notes for
> 9.1, but so far he has done all of the work and it is a little hard to see
> where we have left off and to work together adding the content.
> https://cwiki.apache.or
On Thu, Jun 4, 2020 at 7:58 AM David Sidrane wrote:
> I think _Every PR_ needs a description do begin to be a responsible and
> professional contribution. The small extra level of effort will keep the
> team informed and provide the documentation for the release process. We
> should not have to re
On Wed, Jun 3, 2020 at 5:36 PM Adam Feuer wrote:
> I got stuck, and switched to Linux. But I will give macOS a try again in
> the next few days, and update the instructions if I succeed.
I built a recent master on macOS and it worked. All I had to do was:
* Install gcc-arm-none-eabi using inst
I had this in the original PR I submitted for the templates. That got
changed due to lack of working project experience and vision. The Apache way
is not being followed here: the PMC is not voting on things we should be.
Can we work on process?
David
-Original Message-
From: Nathan Hartm
On Thu, Jun 4, 2020 at 10:07 AM David Sidrane wrote:
> I had this in the original PR I submitted for the templates. That got
> changed due to lack of working project experience and vision. The Apache way
> is not being followed here: the PMC is not voting on things we should be.
>
> Can we work on
Let's discuss what is needed in commit messages PRs
1) Effective team communication
2) Have a problem statement
3) Provide reasoning for solution and alternatives
4) Provide test instructions steps for reproduction
5) Provides content usable in release notes.
Here is a straw man with some reasoni
.
See
https://github.com/nuttx-to-asf/incubator-nuttx/commit/b496ee7ff9adeaa9020e7b07efed8198d4e8e623
The is HORRIBLE!!! God help us.
Brennan, that board is awesome. +1.
Nathan, +1 for the [DISCUSS] thread to talk about PR descriptions/templates.
-adam
On Thu, Jun 4, 2020 at 7:45 AM Nathan Hartman
wrote:
> On Thu, Jun 4, 2020 at 10:07 AM David Sidrane
> wrote:
> > I had this in the original PR I submitted for the templates.
+1 for DISCUSS thread
//Alin
On Thu, Jun 4, 2020, 17:51 Adam Feuer wrote:
> Brennan, that board is awesome. +1.
>
> Nathan, +1 for the [DISCUSS] thread to talk about PR
> descriptions/templates.
>
> -adam
>
> On Thu, Jun 4, 2020 at 7:45 AM Nathan Hartman
> wrote:
>
> > On Thu, Jun 4, 2020 at 1
.
See
https://github.com/nuttx-to-asf/incubator-nuttx/commit/b496ee7ff9adeaa9020e7b07efed8198d4e8e623
The is HORRIBLE!!! God help us.
Full disclosure: I am the guy with the "lack of working project
experience and vision" who correct that original, horrible template.
I did th
On Thu, Jun 4, 2020 at 11:54 AM Gregory Nutt wrote:
> >> See
> >> https://github.com/nuttx-to-asf/incubator-nuttx/commit/b496ee7ff9adeaa9020e7b07efed8198d4e8e623
> >>
> >
> > The is HORRIBLE!!! God help us.
> Full disclosure: I am the guy with the "lack of working project
> experience an
Effective immediately, I intend to reduce my particiapation in the
Apache NuttX project. I will stay on the PPMC and will vote and will an
answer any questions. I will express my opinion when needed (as in the
case of that lousy PT template.
But I will no longer be reviewing PRs, merging PRs
Yes. Simplicity is single most important thing. The entire template
should fit entirely within the PR comment window. It should not be a
punishment to contributors to the project. We will get a better
response if it is simple and usable. No inline instructions, please.
There should not be
On Thu, Jun 4, 2020 at 12:32 PM Gregory Nutt wrote:
> Yes. Simplicity is single most important thing. The entire template
> should fit entirely within the PR comment window. It should not be a
> punishment to contributors to the project. We will get a better
> response if it is simple and usab
Yes. Simplicity is single most important thing. The entire template
should fit entirely within the PR comment window. It should not be a
punishment to contributors to the project. We will get a better
response if it is simple and usable. No inline instructions, please.
There should not be no
Or we can say that between the reviewer and the submitter the fields need
to be filled out? That way it can be a collaboration, and over time
submitters will gain skill in filling the fields out themselves.
+1 for a simple template.
-adam
On Thu, Jun 4, 2020 at 10:19 AM Gregory Nutt wrote:
> >
On Thu, Jun 4, 2020 at 1:19 PM Gregory Nutt wrote:
> Why don't we require that the reviewer fill in those sections. The main
> reason that they are not filled in now is language barrier issues, not
> willingness to contribute. Forcing someone who has marginal English
> skills to write prose to yo
Very good points there. I like the idea of making it a collaborative
effort between the contributors and the reviewers.
It is a courtesy of the contributor to make their code available to the
world. It is the responsibility of the reviewer/committer to assure
that there is sufficient informa
I agree there are 2 extremes: No information and Too much information. No
information leads to hundreds of emails a day with no value. To much
information requires focus to triage. The question I want to know the answer
to is: Do I care about this change, now or in the future?
Personally I think f
About unilateral decisions: We should not make them. We need to discuss and
vote on things.
The vote will be interesting. What will be the two options? The
current template or that god-awful one we had for a few days? Is that
what we would be voting on?
No make up one, with instruction. Let get the best of all the input.
But I think it would help to stop call then by judgmental names. Unless of
course the final one will be god-wonderful :)
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, June 04, 2020 11
But I think it would help to stop call then by judgmental names. Unless of
course the final one will be god-wonderful :)
Are you implying we should accept that crap with no judgement? Doesn't
work that way. That old template was crap and everyone knows it. I
have no problem judging it. G
But I think it would help to stop call then by judgmental names.
Unless of
course the final one will be god-wonderful :)
Are you implying we should accept that crap with no judgement? Doesn't
work that way. That old template was crap and everyone knows it. I
have no problem judging it.
But I think it would help to stop call then by judgmental names.
You mean like referring to me as the guy with the "lack of working
project experience and vision" . You made this personal.
But I think it would help to stop call then by judgmental names.
You mean like referring to me as the guy with the "lack of working
project experience and vision" . You made this personal.
What do you expect then? Courtesy for your stupid ideas?
The numbered list is reasonable as a guideline and good practise to cover at
least most of those things in free text.
But the template in the commit... please, no. I have had enough of those in big
companies and in the end they are just harmful.
Br,
Jukka
- Jukka
David Sidrane kirjoitti torst
On Thu, Jun 4, 2020 at 6:16 AM Nathan Hartman
wrote:
> I didn't leave off; rather, so far I have only documented changes to
> the build system that may require downstream users to make changes to
> build scripts for any custom boards.
>
> Nathan
>
Thanks Nathan,
I have shuffled through about 100
hi,
i'm using FLAT memory model.
i want to use dirname() in my app.
but there seems to be no safe way to use static-buffer returning
functions like this
unless you have very tight control on what you run on your system.
am i correct?
i think it makes sense for nuttx to provide non-standard reentra
30 matches
Mail list logo
