date:20200604






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?

Re: [DISCUSS] requirements for commit messages and PRs




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.

Re: [DISCUSS] requirements for commit messages and PRs






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.  Garbage.


That old, horrible template was replaced immediately because it was 
universally hated.  Not one ever filled out (I think Masayuki checked a 
couple of boxes once).  Otherwise, no one.  The current template is 
doing.  Some people who should know better are ignoring it but a 
significant number of people are doing their best to write something in 
each space.

Re: [DISCUSS] requirements for commit messages and PRs





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.  Garbage.

RE: [DISCUSS] requirements for commit messages and PRs

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:25 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] requirements for commit messages and PRs


> 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?

Re: [DISCUSS] requirements for commit messages and PRs





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?

RE: [DISCUSS] requirements for commit messages and PRs

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 forcing users to have to follow a link to a page with no
information on it is a burdened we should not impose on project members. It
is inconsiderate. So I would like to see the information content upped. Type
it in your own language, if need be, that is what google translate is for.
But the experts need to share the information and add value.

Blank canvases works for some people, paint by number works for others.
Anyone can delete the template data and type whatever they want.

But PLEASE type Something!

About unilateral decisions: We should not make them. We need to discuss and
vote on things.

David



-Original Message-
From: Adam Feuer [mailto:a...@starcat.io]
Sent: Thursday, June 04, 2020 10:26 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] requirements for commit messages and PRs

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:

> >> 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 more then 3 or possible 4 sections.  Users
> >> should
> >> be able to fill out the template with what they already know.
> >>
> >> I would be better to have no template at all than that ugly, repulsive
> >> one that has been proposed.  I like you idea fine.  I think Summay,
> >> changes, Release Notes are all trying to get to the same thing.  A
> >> simple function description is what is needed... that answers all of
> those.
> >>
> >> Impact is optional, but it is nice to know if anything else is affected
> >> by the change.  You gotta admit:
> >>
> >> ## Summary
> >> ## Impact
> >> ## Testing
> >>
> >> Is pretty damn good!  Perhaps "Functional Description of Change" is
> >> better.  Perhaps "Affected Behaviors" is better than "Impact".  Testing
> >> is intentionally vagues.
> > Yes, it is pretty good!
> >
> > I'd like to make it very clear that I do *NOT* advocate creating some
> > big monster of a PR template!!
> >
> > If we take a step back for a moment, the issue that started this
> > discussion is how to make it easier to write Release Notes. Currently
> > we have many PRs that don't explain what they do, so Release Notes
> > writers have to dive into the code to try to find out, so writing
> > Release Notes is a nightmare. The release notes for 9.0 were not so
> > good. I'm trying to improve the 9.1 release notes to make them helpful
> > for our users.
> >
> > Maybe it's enough to keep the current Summary, Impact, Testing
> > template, but come to an agreement that PR reviewers need to enforce
> > that these sections are filled in. At minimum Summary needs to explain
> > the change well enough that Release Notes can be written easily
> > without looking at the code.
>
> 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 your requirements is not a very kind thing to
> do to our good, honest, well-meaning contributors.  Let's help them.
> Let's not make life difficult for them.
>
> Also, if the reviewer fills out those sections we can (1) assure a
> constsistent quality of prose, and (2) it is proof that the reviewer
> understands the issues will enough and did, in fact, do a real review.
>
> I have always tried to help contributors by meeting them half way.  In
> the past, only I ran nxstyle and only I fixed the style errors on
> submitted code.  That was a courtesy and an act that showed my thanks
> for the contributions (I still force push nxstyle fixes to contributors
> branches on occasion).  Let's go that extra mile rather than be some
> kind of an oppressive organization that berates and hassles contributors
> who are just trying to do the right thing.
>
> We don't all have to be assholes.
>
> Greg
>
>
>

-- 
Adam Feuer

Re: [DISCUSS] requirements for commit messages and PRs





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 information for release notes.

Re: [DISCUSS] requirements for commit messages and PRs

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 your requirements is not a very kind thing to
> do to our good, honest, well-meaning contributors.  Let's help them.
> Let's not make life difficult for them.
>
> Also, if the reviewer fills out those sections we can (1) assure a
> constsistent quality of prose, and (2) it is proof that the reviewer
> understands the issues will enough and did, in fact, do a real review.
>
> I have always tried to help contributors by meeting them half way.  In
> the past, only I ran nxstyle and only I fixed the style errors on
> submitted code.  That was a courtesy and an act that showed my thanks
> for the contributions (I still force push nxstyle fixes to contributors
> branches on occasion).  Let's go that extra mile rather than be some
> kind of an oppressive organization that berates and hassles contributors
> who are just trying to do the right thing.

Very good points there. I like the idea of making it a collaborative
effort between the contributors and the reviewers.

Nathan

Re: [DISCUSS] requirements for commit messages and PRs

2020-06-04 Thread Adam Feuer

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:

> >> 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 more then 3 or possible 4 sections.  Users should
> >> be able to fill out the template with what they already know.
> >>
> >> I would be better to have no template at all than that ugly, repulsive
> >> one that has been proposed.  I like you idea fine.  I think Summay,
> >> changes, Release Notes are all trying to get to the same thing.  A
> >> simple function description is what is needed... that answers all of
> those.
> >>
> >> Impact is optional, but it is nice to know if anything else is affected
> >> by the change.  You gotta admit:
> >>
> >> ## Summary
> >> ## Impact
> >> ## Testing
> >>
> >> Is pretty damn good!  Perhaps "Functional Description of Change" is
> >> better.  Perhaps "Affected Behaviors" is better than "Impact".  Testing
> >> is intentionally vagues.
> > Yes, it is pretty good!
> >
> > I'd like to make it very clear that I do *NOT* advocate creating some
> > big monster of a PR template!!
> >
> > If we take a step back for a moment, the issue that started this
> > discussion is how to make it easier to write Release Notes. Currently
> > we have many PRs that don't explain what they do, so Release Notes
> > writers have to dive into the code to try to find out, so writing
> > Release Notes is a nightmare. The release notes for 9.0 were not so
> > good. I'm trying to improve the 9.1 release notes to make them helpful
> > for our users.
> >
> > Maybe it's enough to keep the current Summary, Impact, Testing
> > template, but come to an agreement that PR reviewers need to enforce
> > that these sections are filled in. At minimum Summary needs to explain
> > the change well enough that Release Notes can be written easily
> > without looking at the code.
>
> 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 your requirements is not a very kind thing to
> do to our good, honest, well-meaning contributors.  Let's help them.
> Let's not make life difficult for them.
>
> Also, if the reviewer fills out those sections we can (1) assure a
> constsistent quality of prose, and (2) it is proof that the reviewer
> understands the issues will enough and did, in fact, do a real review.
>
> I have always tried to help contributors by meeting them half way.  In
> the past, only I ran nxstyle and only I fixed the style errors on
> submitted code.  That was a courtesy and an act that showed my thanks
> for the contributions (I still force push nxstyle fixes to contributors
> branches on occasion).  Let's go that extra mile rather than be some
> kind of an oppressive organization that berates and hassles contributors
> who are just trying to do the right thing.
>
> We don't all have to be assholes.
>
> Greg
>
>
>

-- 
Adam Feuer

Re: [DISCUSS] requirements for commit messages and 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 no more then 3 or possible 4 sections.  Users should
be able to fill out the template with what they already know.

I would be better to have no template at all than that ugly, repulsive
one that has been proposed.  I like you idea fine.  I think Summay,
changes, Release Notes are all trying to get to the same thing.  A
simple function description is what is needed... that answers all of those.

Impact is optional, but it is nice to know if anything else is affected
by the change.  You gotta admit:

## Summary
## Impact
## Testing

Is pretty damn good!  Perhaps "Functional Description of Change" is
better.  Perhaps "Affected Behaviors" is better than "Impact".  Testing
is intentionally vagues.

Yes, it is pretty good!

I'd like to make it very clear that I do *NOT* advocate creating some
big monster of a PR template!!

If we take a step back for a moment, the issue that started this
discussion is how to make it easier to write Release Notes. Currently
we have many PRs that don't explain what they do, so Release Notes
writers have to dive into the code to try to find out, so writing
Release Notes is a nightmare. The release notes for 9.0 were not so
good. I'm trying to improve the 9.1 release notes to make them helpful
for our users.

Maybe it's enough to keep the current Summary, Impact, Testing
template, but come to an agreement that PR reviewers need to enforce
that these sections are filled in. At minimum Summary needs to explain
the change well enough that Release Notes can be written easily
without looking at the code.


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 your requirements is not a very kind thing to 
do to our good, honest, well-meaning contributors.  Let's help them.  
Let's not make life difficult for them.


Also, if the reviewer fills out those sections we can (1) assure a 
constsistent quality of prose, and (2) it is proof that the reviewer 
understands the issues will enough and did, in fact, do a real review.


I have always tried to help contributors by meeting them half way.  In 
the past, only I ran nxstyle and only I fixed the style errors on 
submitted code.  That was a courtesy and an act that showed my thanks 
for the contributions (I still force push nxstyle fixes to contributors 
branches on occasion).  Let's go that extra mile rather than be some 
kind of an oppressive organization that berates and hassles contributors 
who are just trying to do the right thing.


We don't all have to be assholes.

Greg

Re: [DISCUSS] requirements for commit messages and PRs

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 usable.  No inline instructions, please.
>
> There should not be no more then 3 or possible 4 sections.  Users should
> be able to fill out the template with what they already know.
>
> I would be better to have no template at all than that ugly, repulsive
> one that has been proposed.  I like you idea fine.  I think Summay,
> changes, Release Notes are all trying to get to the same thing.  A
> simple function description is what is needed... that answers all of those.
>
> Impact is optional, but it is nice to know if anything else is affected
> by the change.  You gotta admit:
>
> ## Summary
> ## Impact
> ## Testing
>
> Is pretty damn good!  Perhaps "Functional Description of Change" is
> better.  Perhaps "Affected Behaviors" is better than "Impact".  Testing
> is intentionally vagues.

Yes, it is pretty good!

I'd like to make it very clear that I do *NOT* advocate creating some
big monster of a PR template!!

If we take a step back for a moment, the issue that started this
discussion is how to make it easier to write Release Notes. Currently
we have many PRs that don't explain what they do, so Release Notes
writers have to dive into the code to try to find out, so writing
Release Notes is a nightmare. The release notes for 9.0 were not so
good. I'm trying to improve the 9.1 release notes to make them helpful
for our users.

Maybe it's enough to keep the current Summary, Impact, Testing
template, but come to an agreement that PR reviewers need to enforce
that these sections are filled in. At minimum Summary needs to explain
the change well enough that Release Notes can be written easily
without looking at the code.

Nathan

Re: [DISCUSS] requirements for commit messages and 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 no more then 3 or possible 4 sections. Users should
be able to fill out the template with what they already know.

I would be better to have no template at all than that ugly, repulsive
one that has been proposed. I like you idea fine. I think Summay,
changes, Release Notes are all trying to get to the same thing. A
simple function description is what is needed... that answers all of those.

Impact is optional, but it is nice to know if anything else is affected
by the change. You gotta admit:

## Summary
## Impact
## Testing

Is pretty damn good! Perhaps "Functional Description of Change" is
better. Perhaps "Affected Behaviors" is better than "Impact". Testing
is intentionally vagues.

Greg

On 6/4/2020 10:23 AM, Nathan Hartman wrote:

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 and vision" who correct that original, horrible template.
I did that with full support and encourgment of all the other people
"lack of working project experience and vision" that I spoke to. The
current template is based on the template used by Sony. I for one, and
I suspect may others, with vote against such an abomination of a template.

I think we should keep the template simple. If it's too complicated,
or too many things to fill out, no one will do it.

Currently we have three headings:

## Summary
## Impact
## Testing

Maybe that should be changed to:

## Changes
## Release Notes
## Testing

The purpose of these sections:

## Changes

Document the change from a NuttX developer's perspective. (In the
past, this went into the CHANGES file.)

## Release Notes

Proposed text for the next version's release notes, to document the
change from a user's perspective.

## Testing

Explain what (if anything) you did to test the changes.

But all of this is worthless if the committers don't enforce it. If a
PR lacks these sections filled in, the committers who review it should
request it to be filled in.

Nathan

Reduced Participation

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, or submitting PRs.

Good luck!  I hope you guys continue to make this product the success 
that it has been for so many years and that you grow it into do much more.


Greg

Re: [DISCUSS] requirements for commit messages and PRs

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 and vision"   who correct that original, horrible template.
> I did that with full support and encourgment of all the other people
> "lack of working project experience and vision" that I spoke to.  The
> current template is based on the template used by Sony.  I for one, and
> I suspect may others, with vote against such an abomination of a template.

I think we should keep the template simple. If it's too complicated,
or too many things to fill out, no one will do it.

Currently we have three headings:

## Summary
## Impact
## Testing

Maybe that should be changed to:

## Changes
## Release Notes
## Testing

The purpose of these sections:

## Changes

Document the change from a NuttX developer's perspective. (In the
past, this went into the CHANGES file.)

## Release Notes

Proposed text for the next version's release notes, to document the
change from a user's perspective.

## Testing

Explain what (if anything) you did to test the changes.

But all of this is worthless if the committers don't enforce it. If a
PR lacks these sections filled in, the committers who review it should
request it to be filled in.

Nathan

Re: Organising Release Notes for 9.1

2020-06-04 Thread Alin Jerpelea

+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 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 process?
> >
> > We should. Would you like to start a [DISCUSS] thread to talk about
> > requirements for commit messages and PR descriptions?
> >
> > Nathan
> >
>
>
> --
> Adam Feuer 
>

Re: [DISCUSS] requirements for commit messages and PRs





.

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 that with full support and encourgment of all the other people 
"lack of working project experience and vision" that I spoke to.  The 
current template is based on the template used by Sony.  I for one, and 
I suspect may others, with vote against such an abomination of a template.

Re: Organising Release Notes for 9.1

2020-06-04 Thread Adam Feuer

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. 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?
>
> We should. Would you like to start a [DISCUSS] thread to talk about
> requirements for commit messages and PR descriptions?
>
> Nathan
>


-- 
Adam Feuer

Re: [DISCUSS] requirements for commit messages and PRs


.

See
https://github.com/nuttx-to-asf/incubator-nuttx/commit/b496ee7ff9adeaa9020e7b07efed8198d4e8e623


The is HORRIBLE!!!  God help us.

[DISCUSS] requirements for commit messages and PRs

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 reasoning.

See
https://github.com/nuttx-to-asf/incubator-nuttx/commit/b496ee7ff9adeaa9020e7b07efed8198d4e8e623

# Pull Request Template

## Title guidelines

Following the guidelines for writing good commit messages
(https://chris.beams.io/posts/git-commit/) and creating a meaningful title
is key in effective team communication.

**do's**
- stm32h7:  Add SDMMC Support
- nsh:  Separate `source` and `sh` for POSIX compliance
- nxstyle:  Fixed Camel case detection
- drivers/serial:  Fixed style violation

**dont's**
- fixed bug
- nxstyle
- PR #12

## Description

**Describe problem solved by the PR**
A clear and concise description of the problem, if any, this PR will solve.
Please also include relevant motivation and context: E.g. The current nsh sh
command violates the POSIX ...

List any dependencies that are required for this change.

**Describe your solution**
A clear and concise description of what you have implemented.

**Describe possible alternatives**
A clear and concise description of alternative solutions  you've considered.

**Additional context**
Add any other context or screenshots for the pr.

Fixes # (issue)

## Type of change

Delete options that are not relevant.

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] This change requires a documentation update

## How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide
instructions so we can reproduce. Please also list any relevant details for
your test configuration

- [ ] Test A
- [ ] Test B

**Test Configuration**:

* Nuttx board/config:
* Hardware:
* Toolchain:

## Checklist:

- [ ] My code follows the style guidelines of this project (NEED link to how
to run checkpatch)
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature
works
- [ ] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
- [ ] I have checked my code and corrected any misspellings (NEED link to
how to run checkpatch spelling)

Re: Organising Release Notes for 9.1

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 process?

We should. Would you like to start a [DISCUSS] thread to talk about
requirements for commit messages and PR descriptions?

Nathan

RE: Organising Release Notes for 9.1

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 Hartman [mailto:hartman.nat...@gmail.com]
Sent: Thursday, June 04, 2020 6:23 AM
To: dev@nuttx.apache.org
Subject: Re: Organising Release Notes for 9.1

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 reverse engineer intent to get the one line "what" and
> "why" of the PRs.

Agreed. Maybe the PR template should include a mandatory Release Notes
section. It doesn't have to be publication-ready text, but it should
be good enough that when release time comes around it becomes a simple
matter to go through PRs, copy-and-paste the text into the appropriate
places in the release notes, and maybe edit to make the text flow
well. If nothing should go in the release notes, e.g., it's just
nxstyle or CI, then write "None." But it will depend on the project's
committers to enforce this, and whoever does the merge should do a
little due diligence and make sure it doesn't just say "None" if it's
a change that should be mentioned in the release notes.

Nathan

Re: Release 9.1

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 instructions from either PX4 or Mynewt
(don't remember which),

>
* Install flock using instructions in our top level readme

* configure && make && make install kconfig-frontends from our tools repo

and after that, 'tools/configure.sh', 'make menuconfig', and 'make' worked
perfectly. One caveat: I have Xcode and its command line tools, and
homebrew, so maybe I have something not mentioned here that's needed.

Nathan

Re: Organising Release Notes for 9.1

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 reverse engineer intent to get the one line "what" and
> "why" of the PRs.

Agreed. Maybe the PR template should include a mandatory Release Notes
section. It doesn't have to be publication-ready text, but it should
be good enough that when release time comes around it becomes a simple
matter to go through PRs, copy-and-paste the text into the appropriate
places in the release notes, and maybe edit to make the text flow
well. If nothing should go in the release notes, e.g., it's just
nxstyle or CI, then write "None." But it will depend on the project's
committers to enforce this, and whoever does the merge should do a
little due diligence and make sure it doesn't just say "None" if it's
a change that should be mentioned in the release notes.

Nathan

Re: Organising Release Notes for 9.1

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.org/confluence/display/NUTTX/NuttX+9.1

Thanks.

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.

Those changes were introduced in these PRs/commits:

PR 763 - 459ad9937377a42785692098ff0d73baaa9551e6

PR 1006 - 6ca46520df38854bf660f9be54957cceede39ded

PR 1066 - bd656888f26c92e8832f0e76b395a5ece7704530, and
  5eae32577e5d5226e5d3027c169eeb369f83f77d

PR 1073 - 9ec9431706fd0eb7c4c4410d84dafff68ff31366,
  8b42ee421a41214093c0238e479d73a1099b0e82,
  567962bd6263bf8809fb63c739f6ec668c69c416, and
  7faf3c0254bb63af89f9eb59beefacb4cba26dd9

PR 1088 - 1a95cce1a3c3ed8b04d1d86b7bd744352cca45a2

PR 1095 - 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0, and
  e83c1400b65c65cbdf59c5abcf2ae368f540faef

I think there remains one recent build system change that I haven't
documented yet.

Nathan

Re: Release 9.1

2020-06-04 Thread Abdelatif Guettouche

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 template for PR text?
> That would make going through them easier. For instance:

We already have a PR template similar to that, we just need to
convince everyone to use it.
The majority do use it, but it's still being ignored for small changes.


On Wed, Jun 3, 2020 at 10:36 PM Adam Feuer  wrote:
>
> Abdelatif,
>
> I haven't tried my instructions on macOS... when I was first starting out,
> 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. Good idea.
>
> Re: the release notes, maybe we can start using a template for PR text?
> That would make going through them easier. For instance:
>
> ### Bug or Feature?
> ### One line summary
> ### Impact
> ### Limitations / TODO
> ### Detail
> ### Testing
>
> If we had this filled out for every PR, it would make creating the Release
> Notes a lot easier.
>
> -adam
>
> On Wed, Jun 3, 2020 at 2:12 PM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > For the licensing, we are taking baby steps by changing only the files
> > that we know won't cause any issue.
> > I think we will continue to do that until we get the necessary ICLAs
> > then we can do a massive substitution.
> > But as have been said in the very beginning, this should not stop us
> > from making releases.
> > The most important part is that we make progress with each release.
> > We are definitely making progress technically, what Brennan is
> > referring to is the fact that IPMC members found it hard to build from
> > source.  I think most of their issues came from not
> > installing/configuring kconfig-frontends which is in a separate
> > repository.
> > BTW, Adam, have you tried the steps of your companion in a fresh
> > installation of, say, macOS?  That might be all we need.
> >
> > Generating release notes is the part that has the most painful work,
> > it took 4 of us last time to get it done.  I still wonder if there is
> > a way to automate that, maybe with good PR summaries and consistent
> > labeling.
> > Nathan created a confluence page to prepare release notes for the 9.1
> > ahead of time.
> >
> > On Wed, Jun 3, 2020 at 4:58 PM Adam Feuer  wrote:
> > >
> > > Brennan,
> > >
> > > What, in your opinion, needs to be done to improve the onboarding
> > process?
> > >
> > > And what would you like to see happen to improve the licensing issues?
> > > Another pass through the files of another section (like we did with
> > sched)
> > > and updating headers? Or...?
> > >
> > > -adam
> > >
> > > On Wed, Jun 3, 2020 at 8:44 AM Brennan Ashton  > >
> > > wrote:
> > >
> > > > On Wed, Jun 3, 2020, 6:16 AM Gregory Nutt  wrote:
> > > >
> > > > > Hi, all
> > > > >
> > > > > If we are serious about getting on a two month release cycle again,
> > now
> > > > > is the time to begin thinking about the 9.1 release. We created the
> > 9.0
> > > > > release branch sometime before the 15th of April.   We signed the
> > > > > release on April 23rd.  So we have some time, but also we need to
> > start
> > > > > get some plans and organization in place.  And we need to think about
> > > > > doing everything we can to make the master stable for that branch.
> > We
> > > > > should hold off large, sweeping changes until we get past that point.
> > > > >
> > > > > Duo... you mentioned that you were interested with assisted with the
> > > > > releases?  Abdelatif was the point man last time.  Perhaps you would
> > > > > want to discuss his experiences with him?
> > > > >
> > > > > Greg
> > > > >
> > > >
> > > > I would agree, but we have made zero progress on improving the
> > onboarding
> > > > process in terms of build and documentation, nor have we made progress
> > on
> > > > the licensing process. I'm not confident that the release would pass.
> > > >
> > > > I am also happy to share more on the steps of the actual release
> > process
> > > > outside of the release notes and branching (thank you Abdelatif that
> > was a
> > > > lot of work) if someone wants to take that on, or I can offer to do
> > that
> > > > portion again. I am happy to do it. It's a lot of little steps but
> > none of
> > > > them are that complicated.
> > > >
> > > > --Brennan
> > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Adam Feuer 
> >
>
>
> --
> Adam Feuer

RE: Organising Release Notes for 9.1