Re: [nuttx] Wiki Backup

[Brennan Ashton]

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
> > SPACEKEY change?
>
> As long as it says "waiting for user” Infra will not look at it. I've
> changed to be “waiting for infra”.
>
I wondered if that was the case.  Thanks for your help.

>
> > 4) When can we point nuttx.org at this for the wiki?
>
> nuttx.org should probably redirect to nuttx.apache.org not the wiki site?
>
>
In the past nuttx.org was just the wiki, but I see that there is a standard
template that we are recommended to start
from.  I have used Jekyll in the past, so happy to get something for
comment.  I am not a commiter or sure what our
git repo is for the website (seemed like it could be git or svn), but I
forked the template in github and am starting with that.

If anyone else is doing this reach out, wikis and websites are not my
favorite, but I want to get this stuff behind us so we
can get back to coding on the project :p

--Brennan

Re: [nuttx] Wiki Backup

[Justin Mclean]

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 look at it. I've changed 
to be “waiting for infra”.

> 4) When can we point nuttx.org at this for the wiki?

nuttx.org should probably redirect to nuttx.apache.org not the wiki site?

Thanks,
Justin

Re: [nuttx] Wiki Backup

[Brennan Ashton]

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 they are used/rendered elsewhere.  This makes it easier to
update them.
https://cwiki.apache.org/confluence/display/NUTTXTEST/Documentation
https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=139629402

2) The HTML files that were part of  /Documentation and a snapshot at
release time of the docs have been run through a tool called inliner
https://github.com/remy/inliner
This makes sure all of the images, css, and js are inlined with the file
instead of linked.  This works around a confluence issue where it cannot
render HTML with relative links.  I have made note of the on the
Documentation page.

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?
https://issues.apache.org/jira/browse/INFRA-19570

4) When can we point nuttx.org at this for the wiki?

--Brennan

On Thu, Dec 19, 2019 at 12:12 AM Alin Jerpelea  wrote:

> 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: dev@nuttx.apache.org
> > Subject: Re: [nuttx] Wiki Backup
> >
> > Did another major round of updates.  I removed a few pages that just
> linked
> > to documentation pages that are already linked in the documentation
> > section.  We need to figure out what to do with what is in the
> > documentation section.
> > For PDFs and the like we can just attach them to the Documentation page
> and
> > then link them in the individual pages, but for the HTML if is a pain to
> > render the images as well.  I did a hack on the graphics one to replace
> the
> > image url, but it is not ideal.
> >
> > There are also places like this where there is a link to download, and
> that
> > should be replaced with an attachment.
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629542
> >
> > You can also use click Page Info to view all the external links for a
> > page.  For example there is a nuttx.org and three youtube links here
> >
> https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=139629542
> >
> > Also about the long URLs Confluence also will generate the short link:
> >
> > https://cwiki.apache.org/confluence/x/5pNSC
> >
> >
> > There are some pages where the import did some goofy things like putting
> > each line of a code block it its own block, but it is very rare and still
> > readable.
> >
> > If others want to help review and fix formatting please do.
> >
> > Justin, I'll ask INFRA if they can fix the space name.
> >
> > Thanks,
> > Brennan
> > 
> >
> > On Mon, Dec 16, 2019 at 12:12 PM David Sidrane 
> > wrote:
> >
> > > Brennan,
> > >
> > > I bet it was grueling. Thank you again Brennan!
> > >
> > > David
> > > -Original Message-
> > > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > > Sent: Monday, December 16, 2019 7:50 AM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: [nuttx] Wiki Backup
> > >
> > > Greg and David,
> > > The page names just need to finish getting updated, I did about 80% of
> > > them. I can finish that today, I just needed to go to sleep last night.
> > > Manually clicking through all the pages was grating on me.
> > >
> > > --Brennan
> > >
> > > On Mon, Dec 16, 2019, 3:21 AM David Sidrane 
> > > wrote:
> > >
> > > > Brennan,
> > > >
> > > > Thank you for your efforts!
> > > >
> > > > Justin: Is there an issue with adding all the PPMC to have the
> ability
> > > > to
> > > > edit the content?
> > > >
> > > > I see some naming that looks like url id became the Page Title:
> > > >
> > > >  For example: NuttX Initialization Sequence is listed under
> > Initsequence
> > > >
> > > > https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence
> > > >
> > > > Also is there a way to maintain the original authors?
> > > >
> > > > David
> > > >
> > > > -Original Message-
> > > > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > > > Sent: Sunday, December 15, 2019 11:16 PM
> > > > To: dev@nuttx.apache.org
> > > > Subject: Re: [nuttx] Wiki Backup
> > > >
> > > > Ok,
> > > > That was a bigger hassle than I expected.  The converter tool was
> > > > getting
> > > > tripped up with odd escaping and generating bad XML files for
> > > > confluence,
> > > > but I think it is good now.
> > > > I also went through and manually cleaned the naming, obvious issues,
> > and
> > > > in

Re: [DISCUSS - NuttX Workflow]

[Nathan Hartman]

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 they're not sure about. But these
> > changes don't require as much oversight. These changes are much more
> > limited in their exposure. They are usually developed by someone to
> > scratch their own itch. Also these are allowed to be feature-
> > incomplete: e.g., it is okay to have partial board support.
>
> I do not agree. MCU and board changes need better scrutiny for many reasons,
> here are some:
>
> 1) Proper patterns applied. This gets misses a lot - consider the "ifdef
> rash" and missed invilotes
> 2) Proper scoping - this just happened in imxrt
> 3) They still can break the build.
> 3) They still can ruin the OS's reputation.
> 4) This is where HW background is needed.
>
> You may want to consider separate levels of scrutiny for MCU's than boards.

Acknowledged.

The issue with boards and MCUs is that the pool of contributors for
these areas is much thinner than the pool of contributors for some of
the more heavily exercised areas.

Now, I can see where a company that produces a board -- and wants to
provide full NuttX support for it in order to sell those boards --
could pay engineers to develop FULL tested and characterized support
for the board and all its features.

But, if it's a volunteer like me, I would likely implement support for
the parts I'm going to use. It's a "scratch your own itch" type of
development. Although this is "incomplete," I would greatly prefer to
have it contributed to NuttX, over rejecting it due to incompleteness,
because it reduces effort for the next person who wants to use that
board, even if they need to implement support for a missing feature.
It's better to start with partial support and implement the extra part
you need, then to start from zero.

Now, I agree that we need to check for proper patterns, proper
scoping, and unbroken build. But we can't necessarily have PMC members
testing changes to boards because they may not have the board. Also,
testing changes may require a whole hardware test setup with
oscilloscope / logic analyzer and we cannot expect PMC members to
spend that much time testing a change. It will never get voted on and
people will become discouraged and stop contributing. So, we must have
a certain amount of trust that the person contributing changes is
doing so in good faith. Perhaps we need a PMC vote, or, say, two non-
PMC committers to agree that changes to board support follow the code
conventions and rules, but their +1 doesn't have to imply that they
have the hardware and actually tested the change. As long as it
follows basic rules and seems legit, it should be committed.

As for protecting the OS's reputation, I think that each board should
have some sort of "Status" score:

* Boards with complete support that are widely exercised and known
  to work correctly out of the box could be given a "Tier 1" status.
  Recommended if you just want to focus on your application and have
  all the hardware details taken care of for you.

* Boards with less support and testing could be categorized as
  "Tier 2" status, meaning that NuttX's support for them might be
  fine for some applications but some board features may be
  unsupported, incomplete, or not well-exercised. Recommended for
  the hardware savvy who don't mind if they have to fix a few issues
  to finish their project.

* "Tier 3" could mean implementation in progress and many features
  are missing or buggy. Recommended for those who want to hack on
  support for the board.

How to arrive at such a status score? This could be problematic, since
not all of us own every single board in NuttX, and even if we did, we
could never volunteer the time that it would take to characterize and
test every board and all its features with NuttX. So we may have to
rely on the word of the implementer and community members who happen
to use a particular board, or we could consider factors like the
number of contributors who have worked on a board, the number of bugs
reported, the number of bugs fixed, time between report and fix, and
word of mouth from the community. Just a thought.

Regarding boards, I'd like to point out that at my job, all boards are
custom boards designed by us. So it is entirely up to us to support a
board. I am guessing that most companies that produce products with
NuttX are doing so with custom boards anyway. I don't think they're
incorporating LaunchPads or Nucleo boards into commercial products.
But that's just my guess.

As far as MCUs go, we could do something similar with "Tiers" (or
other terminology, if you prefer). MCUs might be more heavily
exercised than boards, because the same (or similar) MCU may appear on
several different boards. Also MCUs in the same family tend t

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Justin Mclean]

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

Re: [DISCUSS - NuttX Workflow]

[Nathan Hartman]

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
encouraged to use it.. If they are one solution is to make more frequent
releases.
> 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 detect
> these errors.  Errors in the core OS can persists for months and in at
> least one case I am aware of, years, until some sets up the correct
> instrumented test.

And:

On Thu, Dec 19, 2019 at 4:20 PM Justin Mclean 
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
encouraged to use it.. If they are one solution is to make more frequent
releases.

Many users are only using released code. However, whatever is in "master"
eventually gets released. So if problems creep in unnoticed, downstream
users will be affected. It is only delayed.

I can personally attest that those kinds of errors are extremely difficult
to detect and trace. It does require a special setup with logic analyzer or
oscilloscope, and sometimes other tools, not to mention a whole setup to
produce the right stimuli, several pieces of software that may have to be
written specifically for the test

I have been wracking my brain on and off thinking about how we could set up
an automated test system to find errors related to timing etc.
Unfortunately unlike ordinary software for which you can write an automated
test suite, this sort of embedded RTOS will need specialized hardware to
conduct the tests. That's a subject for another thread and i don't know if
now is the time, but I will post my thoughts eventually.

Nathan

Re: Podling Nuttx Report Reminder - January 2020

[Nathan Hartman]

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:
> https://cwiki.apache.org/confluence/display/incubator/January2020


Much better. Thank you.

Nathan


>

Re: [DISCUSS - NuttX Workflow]

[Justin Mclean]

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 detect these 
> errors.  Errors in the core OS can persists for months and in at least one 
> case I am aware of, years, until some sets up the correct instrumented test.

Isn’t more reviewing / testing done at realise time? I’m curious to why the 
project things this way. If you want to project to grow beyond it’s current 
contributors you may need to change this. Anything setup can be changed so 
perhaps best to revisit discuss later, once the repos are moved, web site set 
up (anyone?) and people are contributing patches here.

Thanks,
Justin

Re: [DISCUSS - NuttX Workflow]

[Gregory Nutt]

] 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 make more frequent 
releases.
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 detect 
these errors.  Errors in the core OS can persists for months and in at 
least one case I am aware of, years, until some sets up the correct 
instrumented test.

Re: Podling Nuttx Report Reminder - January 2020

[Justin Mclean]

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

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

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 judgment and are
> encouraged to discuss anything they're not sure about. But these
> changes don't require as much oversight. These changes are much more
> limited in their exposure. They are usually developed by someone to
> scratch their own itch. Also these are allowed to be feature-
> incomplete: e.g., it is okay to have partial board support.

I do not agree. MCU and board changes need better scrutiny for many reasons,
here are some:

1) Proper patterns applied. This gets misses a lot - consider the "ifdef
rash" and missed invilotes
2) Proper scoping - this just happened in imxrt
3) They still can break the build.
3) They still can ruin the OS's reputation.
4) This is where HW background is needed.

You may want to consider separate levels of scrutiny for MCU's than boards.

One is a many to 1 relation.
One is a 1 to 1.

David

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, December 19, 2019 10:33 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS - NuttX Workflow]


>> I think only 5 emails in the whole list really address these functional
>> requirements.
> Let me add a 6th... (Without mentioning any "stupid" SCMs.)
>
> One thing missing from our earlier discussions is to decide how many
> approvals a change requires. I think this varies by area of the code
> being changed.
>
> As a starting point for further discussion, I suggest something along
> these lines:
>
> Changes that affect the build system should require three +1 binding
> votes and no vetoes from PMC members PLUS at least one report that
> NuttX builds successfully on each supported platform: Windows, Mac,
> Unix, and no reports of breakage caused by the change. Builds on
> Windows using a Unix compatibility layer would be considered Unix for
> this purpose. Any member of the community should be able to report
> whether it builds successfully and on which platform. Between the
> submitter of the patch, PMC members, and testers, this means that at
> least 7 pairs of eyes looks at any change to the build system. This
> high number is necessary because breakage there affects everyone and
> is very disruptive!
>
> Changes to code that affect the core of the OS should require three +1
> binding votes and no vetoes from PMC members and should be accompanied
> by some rationale or justification for the change. If applicable,
> supporting data should be provided, e.g., if it's supposed to improve
> performance, is this backed up by measurements?
>
> 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 they're not sure about. But these
> changes don't require as much oversight. These changes are much more
> limited in their exposure. They are usually developed by someone to
> scratch their own itch. Also these are allowed to be feature-
> incomplete: e.g., it is okay to have partial board support.
>
> In the apps repository: Changes to code in core apps (such as NSH)
> should require two +1 binding votes and no vetoes.
>
> Changes to other non-core areas of apps are at the discretion of the
> committer.
>
> Notwithstanding all of the above, there is the concept of an "obvious
> fix." Any committer may fix things like obvious typos, misspellings,
> grammar mistakes in comments, code formatting violations, that do not
> change the behavior of the code, without the need for voting and
> approvals, etc. Committers are expected to exercise their best
> judgment here.
>
> It is expected that when someone votes +1 on a change, it means that:
>
> * They have studied the change
>
> * Verified that the change meets INVIOLABLES.
>
> * Verified that it does not break POSIX compatibility or OS
> architectural boundaries
>
> * Done testing if feasible
>
> * Weighed any input from the community
>
> Please remember, the above are NOT rules, the above is a starting
> point for discussion as we hash out our requirements.
>
> Please participate, offer your thoughts, criticisms, etc.
>
> Thanks,
> Nathan

Those sound like good rules of thumb to me.  Certainly there are parts
of the OS that require more care and have broader impact that others.

RE: Contributions (PR or patches)

[David Sidrane]

+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 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 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] https://www.apache.org/foundation/how-it-works/legal.html <
> https://www.apache.org/foundation/how-it-works/legal.html>
>
> > On 19 Dec 2019, at 09:15, Alin Jerpelea  wrote:
> >
> > 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 David Sidrane 
> wrote:
> >
> >>> So, how will we keep track of approvals? I assume that GitHub has a
> built
> >> in mechanism for this purpose?
> >>
> >> Nathan,
> >>
> >> Yes it if built for this and from my perspective working on a 93 person
> >> team, with 67 repositories. It is highly efficient, collaborative, and
> >> effective.
> >>
> >> For example:
> >> Ignoring the excellent process integration to create a proper work flow
> >> that keeps master clean and building with full CI integration.
> >>
> >> Have a look Suggested changes:
> >> Suppose you’re collaborating on a repository with an active pull
> request.
> >> A reviewer can look at that pull request, and if they see room for
> >> improvement, suggest a change to the code by leaving a comment. The
> author
> >> can then accept the suggestion with a single click.
> >>
> >> DRAFT PR. You want input on a design. Create a draft PR, get all the
> input
> >> and value add the community has to offer. That will not be merged
> before it
> >> is ready.
> >>
> >> Here is the value I see in this from past experiences: I have had
> multiple
> >> ways to solve a problem and wanted to get the collective expert's feed
> >> back. I Put up a PR for discussion marking it a Work In Progress [WIP]
> and
> >> the next thing I know, my WIP was merged.
> >>
> >> From my perspective patches, unless applied to a branch do not offer a
> >> collaborative resolution method- nor do they provide a way to educate
> the
> >> community, without an undo effort to decode the delta for the
> contributed
> >> patch to what was applied (speaking of the past process).
> >>
> >> Let's get some requirements defined, our goals laid out and then
> >> discuss
> >> the pros and cons of the options for workflow and the tools that exits
> the
> >> make the whole of the PPMC productive. I am reflecting on statements
> like,
> >> "Volunteers with full time jobs" and "Simple for users." We owe it to
> >> ourselves and the community to make this efficient and effective.
> >>
> >> David
> >>
> >> On 2019/12/16 03:35:01, Xiang Xiao  wrote:
> >>> Yes, GitHub has the standard workflow, we just need insert our special
> >>> requirement(style, build and test) into it:
> >>>
> >>
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow
> >>> Here is one example mynewt:
> >>> https://github.com/apache/mynewt-core/pull/2126
> >>>
> >>> Thanks
> >>> Xiang
> >>> On Mon, Dec 16, 2019 at 10:56 AM Nathan Hartman
> >>>  wrote:
> 
>  On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt 
> >> wrote:
> 
> > Sorry to keep running on...
> >
> > Another thing is that we do not want dictate to uses of release what
> > configuration management tools they must use.  In our open source
> > culture, GIT is pervasive, but remember that many corporations
> > prefer
> > commercial SCM systems.
> 
> 
>  Case in point: My $company uses a really awesome SCM: Apache
> >> Subversion :-)
> 
>  So the process is something along these lines:
> 
>  (Please fill in any gaps...)
> 
>  Will we receive a patch, which I'm assuming will come to dev@ in the
> >> form
>  of email attachments, then a NuttX committer looks at it, sees if it
> >> looks
>  reasonable, then converts that into a GitHub PR.
> 
>  Which begs the question: how do we keep track of emailed patches
>  being
>  processed? Perhaps as simple as a committer replying to the email to
> >> say
>  that it's being processed?
> 
>  Once at GitHub then automated tests run (including nxstyle), then ...
> >> ???
> 
>  In certain parts of the system, I think we should have reasonably low
>

RE: [DISCUSS - NuttX Workflow]

[David Sidrane]

Greg, please read the first post again.

RE: [Degrees of freedom under ASF ]

[David Sidrane]

First I would say: It is really good as an It is an archive, leave at that
google, Done!


-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Thursday, December 19, 2019 7:16 AM
To: dev@nuttx.apache.org
Subject: Re: [Degrees of freedom under ASF ]

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 to the list.
>
> Do I understand you correctly? We can use the original google group and
> add a user there with the dev@nuttx.apache.org?

Now that would be interesting, if we could sync the two somehow.

RE: Workflow and Release strategy Proposal (Was RE: Project Emails)

[David Sidrane]

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

Re: [DISCUSS - NuttX Workflow]

[Justin Mclean]

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 is to make more frequent 
releases.
 
Thanks,
Justin

Re: [DISCUSS - NuttX Workflow]

[Gregory Nutt]

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 just all +1 each other patches without doing a real 
review. This project may be different and if it’s not working you can change it.
Sometimes it is good to slow down if there are modifications proposed to 
critical parts of the system.  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.

I see what your concern is (not break the build) but with any CTR (commit then 
review system) any commit can be easily reverted and you have known working 
points (releases) that users can use. How does a system like this help you 
users of NuttX?


It is true that build errors are usually found quickly.  Usually you 
will hear about it in a day or so.  But it is not good public relations 
to break peoples builds; it is unprofessional.  A good qualification 
environment should build on several platforms first:  Linux, Windows 
(native, Cygwin, MSYS2), macOS, free/openBSD, and others (those are the 
main paltforms).  That would minimize the risk of those embarrassments.


Errors in the core OS are much, much more subtle.  You make changes that 
subtly damage scheduling, prioritization, interlocking, priority 
inheritance, real-time performance and not catch problem for months.  
That is because the effect is subtle; the OS just becomes a crappy OS 
for a few release cycles.  That is the big one that I worry most about 
and and slow-down in the workflow for changes that risk those core OS 
features would be well worth it.


Greg

Re: [DISCUSS - NuttX Workflow]

[Justin Mclean]

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 people that just all +1 each other patches without doing a real 
review. This project may be different and if it’s not working you can change 
it. 

My bigger concern is that this may also discourage new people from taking part 
in the project and set the committer bar too high. But each project is free to 
set that where they want.

It also seems a little complex, with different amount of votes required for 
different areas, people are likely to make mistakes. What happens then?

I see what your concern is (not break the build) but with any CTR (commit then 
review system) any commit can be easily reverted and you have known working 
points (releases) that users can use. How does a system like this help you 
users of NuttX?

Thanks,
Justin

Re: [Degrees of freedom under ASF ]

[Gregory Nutt]

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
https://markmail.org/search/
https://nabble.com (for some lists and it’s a more user forum like approach)

While might be possible to keep the google group and have all email copied here 
and thus archived, there would be other things that would need to be carefully 
considered. For context no other project has their main form of communication 
outside of ASF hardware. Some projects communicate a lot via JIRA or GitHub 
issues and these interactions are sent to the projects mailing list. There's a 
project happening to help archive and translate instant messaging, that’s 
probably 6 months or more away from working out how that works with ASF 
infrastructure and ASF values.

One other consideration. Google groups may go away as some point, it’s not like 
google hasn’t removed other services before. While it seems unlikely that it 
will disappear tomorrow, what about in 5 year to 10 years or 20 years? Can 
everyone have access it? For instance, some google services are blocked in 
China. I assume you need a google account to be able to use it, can everyone 
create one to be part of the project? As a comparison the ASF plans to be 
around for 50+ years and keeps access open to everyone.

Thanks,
Justin


And there are things that are just as bad as "going away."  NuttX left 
the Yahoo group because the service deteriorated to the point it was 
unusable.  This was at the time when the world first realized that the 
Yahoo was falling apart.  The group became nearly non-functional.  Mail 
was not being delivered or mail would be delayed for several days and 
finally showed up when it was no longer in context.  It became useless.


And there was the fear that it would go away but that never actually 
happened.


The old Yahoo group is archived at 
https://nuttx.yahoogroups.narkive.com/ but the group itself was deleted.


I would recommend that we do the same with the Google group down the 
road... archive it some where and dismantle the group.  Not right at 
this moment, of course, but when traffic there dies down sufficiently.


Group

Re: [Degrees of freedom under ASF ]

[Justin Mclean]

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 it’s a more user forum like approach)

While might be possible to keep the google group and have all email copied here 
and thus archived, there would be other things that would need to be carefully 
considered. For context no other project has their main form of communication 
outside of ASF hardware. Some projects communicate a lot via JIRA or GitHub 
issues and these interactions are sent to the projects mailing list. There's a 
project happening to help archive and translate instant messaging, that’s 
probably 6 months or more away from working out how that works with ASF 
infrastructure and ASF values.

One other consideration. Google groups may go away as some point, it’s not like 
google hasn’t removed other services before. While it seems unlikely that it 
will disappear tomorrow, what about in 5 year to 10 years or 20 years? Can 
everyone have access it? For instance, some google services are blocked in 
China. I assume you need a google account to be able to use it, can everyone 
create one to be part of the project? As a comparison the ASF plans to be 
around for 50+ years and keeps access open to everyone.

Thanks,
Justin 

Re: [DISCUSS - NuttX Workflow]

[Gregory Nutt]

I think only 5 emails in the whole list really address these functional
requirements.

Let me add a 6th... (Without mentioning any "stupid" SCMs.)

One thing missing from our earlier discussions is to decide how many
approvals a change requires. I think this varies by area of the code
being changed.

As a starting point for further discussion, I suggest something along
these lines:

Changes that affect the build system should require three +1 binding
votes and no vetoes from PMC members PLUS at least one report that
NuttX builds successfully on each supported platform: Windows, Mac,
Unix, and no reports of breakage caused by the change. Builds on
Windows using a Unix compatibility layer would be considered Unix for
this purpose. Any member of the community should be able to report
whether it builds successfully and on which platform. Between the
submitter of the patch, PMC members, and testers, this means that at
least 7 pairs of eyes looks at any change to the build system. This
high number is necessary because breakage there affects everyone and
is very disruptive!

Changes to code that affect the core of the OS should require three +1
binding votes and no vetoes from PMC members and should be accompanied
by some rationale or justification for the change. If applicable,
supporting data should be provided, e.g., if it's supposed to improve
performance, is this backed up by measurements?

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 they're not sure about. But these
changes don't require as much oversight. These changes are much more
limited in their exposure. They are usually developed by someone to
scratch their own itch. Also these are allowed to be feature-
incomplete: e.g., it is okay to have partial board support.

In the apps repository: Changes to code in core apps (such as NSH)
should require two +1 binding votes and no vetoes.

Changes to other non-core areas of apps are at the discretion of the
committer.

Notwithstanding all of the above, there is the concept of an "obvious
fix." Any committer may fix things like obvious typos, misspellings,
grammar mistakes in comments, code formatting violations, that do not
change the behavior of the code, without the need for voting and
approvals, etc. Committers are expected to exercise their best
judgment here.

It is expected that when someone votes +1 on a change, it means that:

* They have studied the change

* Verified that the change meets INVIOLABLES.

* Verified that it does not break POSIX compatibility or OS
architectural boundaries

* Done testing if feasible

* Weighed any input from the community

Please remember, the above are NOT rules, the above is a starting
point for discussion as we hash out our requirements.

Please participate, offer your thoughts, criticisms, etc.

Thanks,
Nathan


Those sound like good rules of thumb to me.  Certainly there are parts 
of the OS that require more care and have broader impact that others.

Re: [DISCUSS - NuttX Workflow]

[Nathan Hartman]

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 both.  The near term objective of the PPMC is just to come up
> with a list -- maybe one page double spaced -- that just summarizes the
> steps that changes will undergo going from a patch (or PR) to being
> merged into master.  Should be pretty simple. These would be the
> "functional" requirements of the workflow.
>
> I think only 5 emails in the whole list really address these functional
> requirements.

Let me add a 6th... (Without mentioning any "stupid" SCMs.)

One thing missing from our earlier discussions is to decide how many
approvals a change requires. I think this varies by area of the code
being changed.

As a starting point for further discussion, I suggest something along
these lines:

Changes that affect the build system should require three +1 binding
votes and no vetoes from PMC members PLUS at least one report that
NuttX builds successfully on each supported platform: Windows, Mac,
Unix, and no reports of breakage caused by the change. Builds on
Windows using a Unix compatibility layer would be considered Unix for
this purpose. Any member of the community should be able to report
whether it builds successfully and on which platform. Between the
submitter of the patch, PMC members, and testers, this means that at
least 7 pairs of eyes looks at any change to the build system. This
high number is necessary because breakage there affects everyone and
is very disruptive!

Changes to code that affect the core of the OS should require three +1
binding votes and no vetoes from PMC members and should be accompanied
by some rationale or justification for the change. If applicable,
supporting data should be provided, e.g., if it's supposed to improve
performance, is this backed up by measurements?

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 they're not sure about. But these
changes don't require as much oversight. These changes are much more
limited in their exposure. They are usually developed by someone to
scratch their own itch. Also these are allowed to be feature-
incomplete: e.g., it is okay to have partial board support.

In the apps repository: Changes to code in core apps (such as NSH)
should require two +1 binding votes and no vetoes.

Changes to other non-core areas of apps are at the discretion of the
committer.

Notwithstanding all of the above, there is the concept of an "obvious
fix." Any committer may fix things like obvious typos, misspellings,
grammar mistakes in comments, code formatting violations, that do not
change the behavior of the code, without the need for voting and
approvals, etc. Committers are expected to exercise their best
judgment here.

It is expected that when someone votes +1 on a change, it means that:

* They have studied the change

* Verified that the change meets INVIOLABLES.

* Verified that it does not break POSIX compatibility or OS
architectural boundaries

* Done testing if feasible

* Weighed any input from the community

Please remember, the above are NOT rules, the above is a starting
point for discussion as we hash out our requirements.

Please participate, offer your thoughts, criticisms, etc.

Thanks,
Nathan

Re: [Degrees of freedom under ASF ]

[Gregory Nutt]

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 dev@nuttx.apache.org?

Now that would be interesting, if we could sync the two somehow.


I tried doing that when we transitioned from the yahoo to the google 
group.  I could not get it to work but I don't remember why.


So you would try to send to dev-subscr...@apache.org from 
nu...@googlegroups.com and send to nuttx+subscr...@googlegroups.com?  
Would you spoof the return address?


All members of the both groups would get the subscribe information.

There might be challenges with full duplex.  I am not sure how you would 
avoid the storms when when message is sent google->apache, then forward 
apache->google, then forwarded again to google->apache, etc.

Re: [Degrees of freedom under ASF ]

[Nathan Hartman]

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 solution is automatically sending that conversion to a 
> > mailing list or bringing back a summary to the list.

I think the biggest reason for keeping communications on the ASF lists
is because of archiving.

Too often on the internet, important resources just disappear in a
puff of smoke one day.

I can give plenty of examples of when this happened but I don't think
that's necessary. I'm sure you've run into enough broken links to
websites that contained something important and no longer exist.

Our communications often document some very important things that
aren't documented anywhere else. By keeping them within the ASF, at
least we're assured that the archives will be around for as long as
the ASF exists, and hopefully that will be a long, long time.

Nathan

Re: [Degrees of freedom under ASF ]

[Nathan Hartman]

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 to the list.
>
> Do I understand you correctly? We can use the original google group and add a 
> user there with the dev@nuttx.apache.org?

Now that would be interesting, if we could sync the two somehow.

Re: [Degrees of freedom under ASF ]

[David Sidrane]

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. We 
> have a lot of history and over time have built up guidelines which describe 
> what has worked well. Sometimes it's not obvious why these guidelines may 
> exists, so ask if you don’t know or understand or think they seem strange. 
> Sometimes these guideline might not work for your project, that’s OK, if you 
> want to do things in a different way discuss it with the incubator PMC. There 
> is not one path for all projects.
> 
> > Am I correct in understanding that ASF requires project dev communications
> > to be in the open and publicly available” ?
> 
> Yes.
> 
> > 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 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 dev@nuttx.apache.org?

> 
> > I ask this for the reason that the lists are very hard to follow.
> 
> Use subject line to guide you, Id suggest using an email client that supports 
> threads and rules to group messages. You don’t have to read everything. Given 
> it is early days, there’s a lot of noise, I think this will get better over 
> time.
> 
> > Who is the moderator on a list?
> 
> There’s a couple of moderators, if you want to be one just ask, but that’s 
> more to accept/reject emails from people who are not subscribed. All emails 
> from a subscribed address are automatically accepted.
> 
> > - If someone is being abusive is that left on the list forever?
> 
> In general yes. It hard to remove emails and they are archived in many public 
> places.
> 
> > How does one correct a mistake in their post?
> 
> Generally just reply and correct the mistake.
> 
> > Is it an ASF edict to not use the existing NuttX slack?
> 
> No but we would prefer conversation on the mailing list for reasons mentioned 
> above.
> 
> > Other than the release procedures and distribution tools/locations is the
> > project free to use any tool we want for development, testing and CI?
> 
> In general yes. Some tools are easier to use as Infra already supports them.
> 
> > Given the history in the name of  ASF: Are we required to support changes
> > by patches?
> > -  What tool does apache support for avoiding duplicate work on
> > patches? Is there a semaphore?
> >- How does a group review a patch collaboratively?
> 
> There’s no ASF requirements here, it's up to the project to work that out.
> 
> Hope that helps and answer your questions. If you have any or just ask.
> 
> Thanks,
> Justin

Re: Podling Nuttx Report Reminder - January 2020

[Nathan Hartman]

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 https://cwiki.apache.org/confluence/display/incubator/January2019,
is it yet to be created?

Thanks,
Nathan

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Justin Mclean]

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 not be in your time zone or may not 
be able to work on the project during their $dayjob, asynchronous communication 
(i.e email) is preferred as it allows everyone a chance to be involved. There 
are other good reason as well previously discussed.

While I'm a user of Slack and follow about 20 slack workspaces I'm not going to 
closely follow any NuttX slack channel, following the mailing list is all that 
should be needed o know what is going on in a project.

Thanks,
Justin

Re: [Degrees of freedom under ASF ]

[Duo Zhang]

In general, all discussion should happen on the infrastruct hosted by ASF,
like mailing-list, JIRA, etc. This is what I have learned in the past.
And when GitHub becomes popular, the solution is to send the comments on
GitHub to a special mailing list of the project to record them on the
infrastructure hosted by ASF. And now we start to slack, so I'm not sure if
this is a strict rule now. But anyway, I think all discussion should happen
in public, so Greg has archived the private slack channels, which I think
is fine. Maybe Justin and Junping could better answer this question.

And on developing, there is no rule in ASF on how to do development. You
PMC members and committers can decide what is the suitable way. The only
limitation is that, the discussion should be public.

For me, I suggest we use GitHub PR, after the repo migration is done. And I
thiknk it is free for others to send the patch directly to you or Greg or
other committers(since it seems that this mailing-list is not suitable for
attachment), you could help opening a PR, just describe clearly that where
is the patch come from.

Thanks.

David Sidrane  于2019年12月19日周四 下午9:13写道：

> 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 not want to be taking statements out of context and acting on them
> without asking questions as this could severely curtail the growth of this
> project.
>
>
> === Questions ===
>
> Am I correct in understanding that ASF requires project dev communications
> to be in the open and publicly available” ?
>
> Does this need to be on only these mailing lists we have been provided by
> ASF? Or can we be using Google Groups and mirror the reference the list?
>
> I ask this for the reason that the lists are very hard to follow. Granted
> I may be using them wrong, but having 150 emails a day that lack any
> context is more noise than signal and I find it a HUGE a waste of time. If
> this is the only option I am open to be instructed on how to use them
> better.
>
> Who is the moderator on a list?
> - If someone is being abusive is that left on the list forever?
> How does one correct a mistake in their post?
>
> Is it an ASF edict to not use the existing NuttX slack?
>
> Other than the release procedures and distribution tools/locations is the
> project free to use any tool we want for development, testing and CI?
>
> Given the history in the name of  ASF: Are we required to support changes
> by patches?
> -  What tool does apache support for avoiding duplicate work on
> patches? Is there a semaphore?
> - How does a group review a patch collaboratively?
>
>
> David
>

Re: [Degrees of freedom under ASF ]

[Justin Mclean]

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 it's not obvious why these guidelines may exists, so ask 
if you don’t know or understand or think they seem strange. Sometimes these 
guideline might not work for your project, that’s OK, if you want to do things 
in a different way discuss it with the incubator PMC. There is not one path for 
all projects.

> Am I correct in understanding that ASF requires project dev communications
> to be in the open and publicly available” ?

Yes.

> 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 solution is automatically sending that conversion to a mailing list or 
bringing back a summary to the list.

> I ask this for the reason that the lists are very hard to follow.

Use subject line to guide you, Id suggest using an email client that supports 
threads and rules to group messages. You don’t have to read everything. Given 
it is early days, there’s a lot of noise, I think this will get better over 
time.

> Who is the moderator on a list?

There’s a couple of moderators, if you want to be one just ask, but that’s more 
to accept/reject emails from people who are not subscribed. All emails from a 
subscribed address are automatically accepted.

> - If someone is being abusive is that left on the list forever?

In general yes. It hard to remove emails and they are archived in many public 
places.

> How does one correct a mistake in their post?

Generally just reply and correct the mistake.

> Is it an ASF edict to not use the existing NuttX slack?

No but we would prefer conversation on the mailing list for reasons mentioned 
above.

> Other than the release procedures and distribution tools/locations is the
> project free to use any tool we want for development, testing and CI?

In general yes. Some tools are easier to use as Infra already supports them.

> Given the history in the name of  ASF: Are we required to support changes
> by patches?
> -  What tool does apache support for avoiding duplicate work on
> patches? Is there a semaphore?
>- How does a group review a patch collaboratively?

There’s no ASF requirements here, it's up to the project to work that out.

Hope that helps and answer your questions. If you have any or just ask.

Thanks,
Justin

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Gregory Nutt]

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


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.

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Gregory Nutt]

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

Re: [DISCUSS - NuttX Workflow]

[Gregory Nutt]

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 this hat repo is completely
optional and that I will never ever have to use it, I'm okay. let me use my two
repos as usual and play with your hat submodules without annoying anyone else.


But, if this workflow requires such a complex string of git commands including
rebase anytime I have to push anything to the apps or nuttx repo, I dont want to
do it.


Again just my opinion.

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 both.  The near term objective of the PPMC is just to come up 
with a list -- maybe one page double spaced -- that just summarizes the 
steps that changes will undergo going from a patch (or PR) to being 
merged into master.  Should be pretty simple. These would be the 
"functional" requirements of the workflow.


I think only 5 emails in the whole list really address these functional 
requirements.   The reset is all rambling git and github talk that 
completely buries the goal to establish clean functional requirements.  
Details of the use of git, any special testing setups in git, and all of 
that is part of the implementation phase.  Mixing implementation and 
functional specification is always a disaster.


You should not have to be concerned now and you should having this 
conversations but, like everything else, you have been swept into the 
chaos vortex.  Abandon hope all ye who enter here.

[Degrees of freedom under ASF ]

[David Sidrane]

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 not want to be taking statements out of context and acting on them
without asking questions as this could severely curtail the growth of this
project.


=== Questions ===

Am I correct in understanding that ASF requires project dev communications
to be in the open and publicly available” ?

Does this need to be on only these mailing lists we have been provided by
ASF? Or can we be using Google Groups and mirror the reference the list?

I ask this for the reason that the lists are very hard to follow. Granted
I may be using them wrong, but having 150 emails a day that lack any
context is more noise than signal and I find it a HUGE a waste of time. If
this is the only option I am open to be instructed on how to use them
better.

Who is the moderator on a list?
- If someone is being abusive is that left on the list forever?
How does one correct a mistake in their post?

Is it an ASF edict to not use the existing NuttX slack?

Other than the release procedures and distribution tools/locations is the
project free to use any tool we want for development, testing and CI?

Given the history in the name of  ASF: Are we required to support changes
by patches?
-  What tool does apache support for avoiding duplicate work on
patches? Is there a semaphore?
- How does a group review a patch collaboratively?


David

Re: [DISCUSS - NuttX Workflow]

[Jonas Vautherin]

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 consequences as creating a CSV file in
which we would write which commits of apps/ go with which commits of
nuttx/: you can create a file, use it, and remove it, and that cannot have
any negative impact. But it can help.

Let's go one step further: not everybody has to adhere to the hat repo. One
could still use both repos like they always did. But other would still
benefit from it.

Best,
Jonas Vautherin

Re: Workflow and Release strategy Proposal (Was RE: Project Emails)

[Flavio Junqueira]

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 "under one roof" so to speak, at
>>> dev@nuttx.apache.org. I think the Slack, the Google Group, the
>>> LinkedIn Group, and any other forums that fragment participants,
>>> should wind up soon. Whenever we reply to a message there, we should
>>> remind people that those forums are deprecated and that they should
>>> join dev@nuttx.apache.org.
>>> 
>> I think at least the LinkedIn group is not in this category of
>> removing users from the mailing list, quite the opposite. The LinkedIn
>> group goal is to advertise and show projects and products using NuttX.
>> Many people discovered NuttX thanks our announcements there. There is
>> not a discussion group in the Linkedin, but only a showcase for NuttX.
> 
> The LinkedIn group really is a different creature.  It has thousands of 
> subscribers and close to no participation.  Alan is essentially the only 
> poster there.
> 
> I am willing to shut down the Slack right now, at this moment. Every time I 
> proposed doing that, people balk because there might be something of 
> importance there.  There might be, but it would be in a closed channel or a 
> person-to-person conversation.  I think it should go now, but I need support 
> and concurrence to take that step.
> 
> Just speak the words and it is gone.
> 

Re: [DISCUSS - NuttX Workflow]

[Juha Niskanen (Haltian)]

-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? Not much sense to reorganize 
everything at the same time.

Some of our projects don't need apps, some use heavily customized apps instead 
of the one from Greg's tree, some need just NSH. When one is supporting 
multiple NuttX-based products, there can be many apps trees, all different or 
of different versions. We use repo to integrate NuttX with other software. 
Using repo + submodules would just add extra dimension of complexity for no 
reason. I don't want to change our company's CI and test systems because of 
submodules. There is no client to bill for the hours.

Best Regards,
   Juha Niskanen



From: Sebastien Lorquet 
Sent: Thursday, December 19, 2019 10:32 AM
To: dev@nuttx.apache.org 
Subject: Re: [DISCUSS - NuttX Workflow]

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 this hat repo is completely
optional and that I will never ever have to use it, I'm okay. let me use my two
repos as usual and play with your hat submodules without annoying anyone else.


But, if this workflow requires such a complex string of git commands including
rebase anytime I have to push anything to the apps or nuttx repo, I dont want to
do it.


Again just my opinion.

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.

Sebastien

Le 18/12/2019 à 15:20, David Sidrane a écrit :
>> what advantage does in fact the submodule method bring?
> See below
>
>> Even with a hat repository that contains two submodules (apps and nuttx),
>> you
>> will have to send separate pull requests for each submodule, right?
> Yes. But they com nit in 1 Atomic operation.
>
>
> Submodules 101
>
> This example is with write access on the repo - for committers
>
> git clone  NuttX
> cd NuttX
> git checkout master
> git submodule sync --recursive && git submodule update --init --recursive
>
> git checkout -b master_add_tof_driver
>
> cd nuttx
> git checkout -b master_add_tof_driver
>
> #work and commit - rebase on self and remove drabble.
> rebase -i master
> #reorder, squash and fixup the commits (learn about mv-changes is your
> friend) - you will look organized.
>
> cd apps
> git checkout -b master_add_tof_driver
>
> #work and commit - rebase on self and remove cruft and noise.
> rebase -i master
> #reorder, squash and fixup the commits (learn about mv-changes it is your
> friend) - you will look organized.
>
> #Build and test locally.
> ## AOK
>
> cd apps
> git push origin master_add_tof_driver
>
> cd nuttx
> git push origin master_add_tof_driver
>
> cd .. (NuttX)
> git add nuts apps
> git commit "Update NuttX with TOF driver"
>
> git push origin master_add_tof_driver
>
> Ok so now (shal simplified to compare them)
>
> NuttX master shal  point to
>   \nuttx master shal 
>   \apps master shal 
>
> NuttX master_add_tof_driver 
>   \nuttx master shal aaa
>   \apps master shal bbb
>
> merge PR from apps to master apps
> merge PR from nuttx to master nuttx
>
> NuttX master shal  point to (still builds and runs)
>   \nuttx master shal 
>   \apps master shal 
>
> But the branch master of the submodules
>
>   \nuttx master shal aaa
>   \apps master shal bbb
>
>
> merge PR from NuttX to master NuttX (atomic replacement)
> NuttX master shal z point to
>   \nuttx master shal aaa
>   \apps master shal bbb
>
>
>
> -Original Message-
> From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
> Sent: Wednesday, December 18, 2019 5:52 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS - NuttX Workflow]
>
> Wait,
>
> what advantage does in fact the submodule method bring?
>
> Even with a hat repository that contains two submodules (apps and nuttx),
> you
> will have to send separate pull requests for each submodule, right?
>
> Sebastien
>
> Le 18/12/2019 à 14:40, Gregory Nutt a écrit :
>> On 12/18/2019 4:23 AM, David Sidrane wrote:
>>> That is precisely what submodules do:submodules aggregate on a single
>>> SHAL N
>>> repositories.
>>>
>>> The problem is: How to have atomic checkout of the correct configuration
>>> with
>>> out a temporal shift?
>>>
>>> Please describe how you would do this. Give detailed steps.
>> I don't see any difference in versioning with submodules.  You have to
>> explicitly state the UUID you are using in the submodule (unless there is
>> a
>> GIT sub-module trick I don't know).
>>
>> So how would you checkout the correct config

Re: Contributions (PR or patches)

[Brennan Ashton]

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 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] https://www.apache.org/foundation/how-it-works/legal.html <
> https://www.apache.org/foundation/how-it-works/legal.html>
>
> > On 19 Dec 2019, at 09:15, Alin Jerpelea  wrote:
> >
> > 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 David Sidrane 
> wrote:
> >
> >>> So, how will we keep track of approvals? I assume that GitHub has a
> built
> >> in mechanism for this purpose?
> >>
> >> Nathan,
> >>
> >> Yes it if built for this and from my perspective working on a 93 person
> >> team, with 67 repositories. It is highly efficient, collaborative, and
> >> effective.
> >>
> >> For example:
> >> Ignoring the excellent process integration to create a proper work flow
> >> that keeps master clean and building with full CI integration.
> >>
> >> Have a look Suggested changes:
> >> Suppose you’re collaborating on a repository with an active pull
> request.
> >> A reviewer can look at that pull request, and if they see room for
> >> improvement, suggest a change to the code by leaving a comment. The
> author
> >> can then accept the suggestion with a single click.
> >>
> >> DRAFT PR. You want input on a design. Create a draft PR, get all the
> input
> >> and value add the community has to offer. That will not be merged
> before it
> >> is ready.
> >>
> >> Here is the value I see in this from past experiences: I have had
> multiple
> >> ways to solve a problem and wanted to get the collective expert's feed
> >> back. I Put up a PR for discussion marking it a Work In Progress [WIP]
> and
> >> the next thing I know, my WIP was merged.
> >>
> >> From my perspective patches, unless applied to a branch do not offer a
> >> collaborative resolution method- nor do they provide a way to educate
> the
> >> community, without an undo effort to decode the delta for the
> contributed
> >> patch to what was applied (speaking of the past process).
> >>
> >> Let's get some requirements defined, our goals laid out and then discuss
> >> the pros and cons of the options for workflow and the tools that exits
> the
> >> make the whole of the PPMC productive. I am reflecting on statements
> like,
> >> "Volunteers with full time jobs" and "Simple for users." We owe it to
> >> ourselves and the community to make this efficient and effective.
> >>
> >> David
> >>
> >> On 2019/12/16 03:35:01, Xiang Xiao  wrote:
> >>> Yes, GitHub has the standard workflow, we just need insert our special
> >>> requirement(style, build and test) into it:
> >>>
> >>
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow
> >>> Here is one example mynewt:
> >>> https://github.com/apache/mynewt-core/pull/2126
> >>>
> >>> Thanks
> >>> Xiang
> >>> On Mon, Dec 16, 2019 at 10:56 AM Nathan Hartman
> >>>  wrote:
> 
>  On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt 
> >> wrote:
> 
> > Sorry to keep running on...
> >
> > Another thing is that we do not want dictate to uses of release what
> > configuration management tools they must use.  In our open source
> > culture, GIT is pervasive, but remember that many corporations prefer
> > commercial SCM systems.
> 
> 
>  Case in point: My $company uses a really awesome SCM: Apache
> >> Subversion :-)
> 
>  So the process is something along these lines:
> 
>  (Please fill in any gaps...)
> 
>  Will we receive a patch, which I'm assuming will come to dev@ in the
> >> form
>  of email attachments, then a NuttX committer looks at it, sees if it
> >> looks
>  reasonable, then converts that into a GitHub PR.
> 
>  Which begs the question: how do we keep track of emailed patches being
>  processed? Perhaps as simple as a committer replying to the email to
> >> say
>  that it's being processed?
> 
>  Once at GitHub then automated tests run (including nxstyle), then ...
> >> ???
> 
>  In certain parts of the system, I think we should have reasonably low
>  barriers to getting contributions in. Drivers for adding, say, SPI
> >> support
>  to some chip shouldn't require too much scrutiny provided they meet
> the
>  coding standard...
> 
>  But:
> 
>

Re: Contributions (PR or patches)

[Flavio Junqueira]

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] https://www.apache.org/foundation/how-it-works/legal.html 


> On 19 Dec 2019, at 09:15, Alin Jerpelea  wrote:
> 
> 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 David Sidrane  wrote:
> 
>>> So, how will we keep track of approvals? I assume that GitHub has a built
>> in mechanism for this purpose?
>> 
>> Nathan,
>> 
>> Yes it if built for this and from my perspective working on a 93 person
>> team, with 67 repositories. It is highly efficient, collaborative, and
>> effective.
>> 
>> For example:
>> Ignoring the excellent process integration to create a proper work flow
>> that keeps master clean and building with full CI integration.
>> 
>> Have a look Suggested changes:
>> Suppose you’re collaborating on a repository with an active pull request.
>> A reviewer can look at that pull request, and if they see room for
>> improvement, suggest a change to the code by leaving a comment. The author
>> can then accept the suggestion with a single click.
>> 
>> DRAFT PR. You want input on a design. Create a draft PR, get all the input
>> and value add the community has to offer. That will not be merged before it
>> is ready.
>> 
>> Here is the value I see in this from past experiences: I have had multiple
>> ways to solve a problem and wanted to get the collective expert's feed
>> back. I Put up a PR for discussion marking it a Work In Progress [WIP] and
>> the next thing I know, my WIP was merged.
>> 
>> From my perspective patches, unless applied to a branch do not offer a
>> collaborative resolution method- nor do they provide a way to educate the
>> community, without an undo effort to decode the delta for the contributed
>> patch to what was applied (speaking of the past process).
>> 
>> Let's get some requirements defined, our goals laid out and then discuss
>> the pros and cons of the options for workflow and the tools that exits the
>> make the whole of the PPMC productive. I am reflecting on statements like,
>> "Volunteers with full time jobs" and "Simple for users." We owe it to
>> ourselves and the community to make this efficient and effective.
>> 
>> David
>> 
>> On 2019/12/16 03:35:01, Xiang Xiao  wrote:
>>> Yes, GitHub has the standard workflow, we just need insert our special
>>> requirement(style, build and test) into it:
>>> 
>> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow
>>> Here is one example mynewt:
>>> https://github.com/apache/mynewt-core/pull/2126
>>> 
>>> Thanks
>>> Xiang
>>> On Mon, Dec 16, 2019 at 10:56 AM Nathan Hartman
>>>  wrote:
 
 On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt 
>> wrote:
 
> Sorry to keep running on...
> 
> Another thing is that we do not want dictate to uses of release what
> configuration management tools they must use.  In our open source
> culture, GIT is pervasive, but remember that many corporations prefer
> commercial SCM systems.
 
 
 Case in point: My $company uses a really awesome SCM: Apache
>> Subversion :-)
 
 So the process is something along these lines:
 
 (Please fill in any gaps...)
 
 Will we receive a patch, which I'm assuming will come to dev@ in the
>> form
 of email attachments, then a NuttX committer looks at it, sees if it
>> looks
 reasonable, then converts that into a GitHub PR.
 
 Which begs the question: how do we keep track of emailed patches being
 processed? Perhaps as simple as a committer replying to the email to
>> say
 that it's being processed?
 
 Once at GitHub then automated tests run (including nxstyle), then ...
>> ???
 
 In certain parts of the system, I think we should have reasonably low
 barriers to getting contributions in. Drivers for adding, say, SPI
>> support
 to some chip shouldn't require too much scrutiny provided they meet the
 coding standard...
 
 But:
 
 In some critical parts, including the build system and OS internals
>> like
 the scheduler, we need a process whereby several pairs of eyes will
>> look at
 the PR and agree that it should be merged. For example, say, we need N
>> +1s
 and zero -1s for any changes that affect those parts... (the value of N
 will need discussion but that is a subject for another day).
 
 So, how will we keep track of approvals? I assume that GitHub has a
>> built
 in mechanism for this purpose?
>

Re: Confluence viewpdf macro

[Justin Mclean]

Hi,

> Seems as if the whole Apache Confluence server is down now.  Is there a
> place to see the status of Apache infrastructure resources?

https://status.apache.org  and it looks like everything seem to be fine at the 
moment.

https://cwiki.apache.org/confluence/display/NUTTXTEST is working for me, it 
seem Infra still hasn’t changed the key.

Thanks,
Justin

Re: [DISCUSS - NuttX Workflow]

[Sebastien Lorquet]

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 this hat repo is completely
optional and that I will never ever have to use it, I'm okay. let me use my two
repos as usual and play with your hat submodules without annoying anyone else.


But, if this workflow requires such a complex string of git commands including
rebase anytime I have to push anything to the apps or nuttx repo, I dont want to
do it.


Again just my opinion.

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.

Sebastien

Le 18/12/2019 à 15:20, David Sidrane a écrit :
>> what advantage does in fact the submodule method bring?
> See below
>
>> Even with a hat repository that contains two submodules (apps and nuttx),
>> you
>> will have to send separate pull requests for each submodule, right?
> Yes. But they com nit in 1 Atomic operation.
>
>
> Submodules 101
>
> This example is with write access on the repo - for committers
>
> git clone  NuttX
> cd NuttX
> git checkout master
> git submodule sync --recursive && git submodule update --init --recursive
>
> git checkout -b master_add_tof_driver
>
> cd nuttx
> git checkout -b master_add_tof_driver
>
> #work and commit - rebase on self and remove drabble.
> rebase -i master
> #reorder, squash and fixup the commits (learn about mv-changes is your
> friend) - you will look organized.
>
> cd apps
> git checkout -b master_add_tof_driver
>
> #work and commit - rebase on self and remove cruft and noise.
> rebase -i master
> #reorder, squash and fixup the commits (learn about mv-changes it is your
> friend) - you will look organized.
>
> #Build and test locally.
> ## AOK
>
> cd apps
> git push origin master_add_tof_driver
>
> cd nuttx
> git push origin master_add_tof_driver
>
> cd .. (NuttX)
> git add nuts apps
> git commit "Update NuttX with TOF driver"
>
> git push origin master_add_tof_driver
>
> Ok so now (shal simplified to compare them)
>
> NuttX master shal  point to
>   \nuttx master shal 
>   \apps master shal 
>
> NuttX master_add_tof_driver 
>   \nuttx master shal aaa
>   \apps master shal bbb
>
> merge PR from apps to master apps
> merge PR from nuttx to master nuttx
>
> NuttX master shal  point to (still builds and runs)
>   \nuttx master shal 
>   \apps master shal 
>
> But the branch master of the submodules
>
>   \nuttx master shal aaa
>   \apps master shal bbb
>
>
> merge PR from NuttX to master NuttX (atomic replacement)
> NuttX master shal z point to
>   \nuttx master shal aaa
>   \apps master shal bbb
>
>
>
> -Original Message-
> From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
> Sent: Wednesday, December 18, 2019 5:52 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS - NuttX Workflow]
>
> Wait,
>
> what advantage does in fact the submodule method bring?
>
> Even with a hat repository that contains two submodules (apps and nuttx),
> you
> will have to send separate pull requests for each submodule, right?
>
> Sebastien
>
> Le 18/12/2019 à 14:40, Gregory Nutt a écrit :
>> On 12/18/2019 4:23 AM, David Sidrane wrote:
>>> That is precisely what submodules do:submodules aggregate on a single
>>> SHAL N
>>> repositories.
>>>
>>> The problem is: How to have atomic checkout of the correct configuration
>>> with
>>> out a temporal shift?
>>>
>>> Please describe how you would do this. Give detailed steps.
>> I don't see any difference in versioning with submodules.  You have to
>> explicitly state the UUID you are using in the submodule (unless there is
>> a
>> GIT sub-module trick I don't know).
>>
>> So how would you checkout the correct configuration with sub-modules.
>> Seems
>> to me that it is the same issue.
>>
>> I would vote about 18billion minus for this change.  But architecture
>> designs
>> are not justified by blantant expediency.
>>
>> Let's not go this way.
>>
>>

Re: Project Emails

[Alin Jerpelea]

+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.
>
> Sebastien
>
> On 12/13/19 3:28 AM, Anthony Merlino wrote:
> > I think submodules are a good way to go. That would leave us with 3 repos
> > as the core Apache NuttX. One for 'nuttx' which, is Greg suggests, should
> > always be exclusively the OS. One for 'apps'. And one for "linking" them
> > together, and for providing other NuttX infrastructure that may not be
> > appropriate in the core OS repo.
> >
> > [image: photo]
> > *Anthony Merlino*
> > CTO & Co-founder, Verge Aero
> > (609)-319-1399
> >
> >
> >
> > On Thu, Dec 12, 2019 at 8:17 PM David Sidrane 
> > wrote:
> >
> >> How about sub modules? We atomically tag across both to keep the
> project in
> >> proper synchronization.
> >>
> >> David
> >>
> >> -Original Message-
> >> From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> >> Sent: Thursday, December 12, 2019 10:55 AM
> >> To: dev@nuttx.apache.org
> >> Subject: Re: Project Emails
> >>
> >> On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt 
> wrote:
> >>> A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is
> the
> >>> operating system proper; apps/ is a collection of applications that may
> >>> or maynot be used with the operating system proper.  These applications
> >>> including some key things and I think most people want to incorporate
> >>> some subset of applications into their project.
> >>>
> >>> But since the applications are NOT part of the operating system they do
> >>> need to remain separate.  I would argue against trying to merge
> >>> application code into the operating system.  So I think we have to
> >>> consider these two separate releases.  We historically release them
> >>> together as a matched pair so that the use can be user that they
> >>> interoperate properly.
> >> +1 : I agree that nuttx and apps should stay separate.
> >>
> >> That begs the question, are we going to have two separate Git
> >> repositories? Because Git lacks support for multiple projects in one
> >> repository. (There's nothing in Git that prevents you from trying, but
> >> Git does not have the features that make the "monorepo"/"megarepo"
> >> pattern work; e.g., it does not have sparse/partial working copies or
> >> clones. Trying to combine nuttx and apps into one repository would
> >> force everyone to clone a lot of content they may not need/want and
> >> which may complicate building the RTOS with only their custom
> >> applications.)
> >>
> >> Nathan
> >>
>

Re: Contributions (PR or patches)

[Alin Jerpelea]

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 David Sidrane  wrote:

> > So, how will we keep track of approvals? I assume that GitHub has a built
> in mechanism for this purpose?
>
> Nathan,
>
> Yes it if built for this and from my perspective working on a 93 person
> team, with 67 repositories. It is highly efficient, collaborative, and
> effective.
>
> For example:
> Ignoring the excellent process integration to create a proper work flow
> that keeps master clean and building with full CI integration.
>
> Have a look Suggested changes:
>  Suppose you’re collaborating on a repository with an active pull request.
> A reviewer can look at that pull request, and if they see room for
> improvement, suggest a change to the code by leaving a comment. The author
> can then accept the suggestion with a single click.
>
> DRAFT PR. You want input on a design. Create a draft PR, get all the input
> and value add the community has to offer. That will not be merged before it
> is ready.
>
> Here is the value I see in this from past experiences: I have had multiple
> ways to solve a problem and wanted to get the collective expert's feed
> back. I Put up a PR for discussion marking it a Work In Progress [WIP] and
> the next thing I know, my WIP was merged.
>
> From my perspective patches, unless applied to a branch do not offer a
> collaborative resolution method- nor do they provide a way to educate the
> community, without an undo effort to decode the delta for the contributed
> patch to what was applied (speaking of the past process).
>
> Let's get some requirements defined, our goals laid out and then discuss
> the pros and cons of the options for workflow and the tools that exits the
> make the whole of the PPMC productive. I am reflecting on statements like,
> "Volunteers with full time jobs" and "Simple for users." We owe it to
> ourselves and the community to make this efficient and effective.
>
> David
>
> On 2019/12/16 03:35:01, Xiang Xiao  wrote:
> > Yes, GitHub has the standard workflow, we just need insert our special
> > requirement(style, build and test) into it:
> >
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow
> > Here is one example mynewt:
> > https://github.com/apache/mynewt-core/pull/2126
> >
> > Thanks
> > Xiang
> > On Mon, Dec 16, 2019 at 10:56 AM Nathan Hartman
> >  wrote:
> > >
> > > On Sun, Dec 15, 2019 at 9:12 PM Gregory Nutt 
> wrote:
> > >
> > > > Sorry to keep running on...
> > > >
> > > > Another thing is that we do not want dictate to uses of release what
> > > > configuration management tools they must use.  In our open source
> > > > culture, GIT is pervasive, but remember that many corporations prefer
> > > > commercial SCM systems.
> > >
> > >
> > > Case in point: My $company uses a really awesome SCM: Apache
> Subversion :-)
> > >
> > > So the process is something along these lines:
> > >
> > > (Please fill in any gaps...)
> > >
> > > Will we receive a patch, which I'm assuming will come to dev@ in the
> form
> > > of email attachments, then a NuttX committer looks at it, sees if it
> looks
> > > reasonable, then converts that into a GitHub PR.
> > >
> > > Which begs the question: how do we keep track of emailed patches being
> > > processed? Perhaps as simple as a committer replying to the email to
> say
> > > that it's being processed?
> > >
> > > Once at GitHub then automated tests run (including nxstyle), then ...
> ???
> > >
> > > In certain parts of the system, I think we should have reasonably low
> > > barriers to getting contributions in. Drivers for adding, say, SPI
> support
> > > to some chip shouldn't require too much scrutiny provided they meet the
> > > coding standard...
> > >
> > > But:
> > >
> > > In some critical parts, including the build system and OS internals
> like
> > > the scheduler, we need a process whereby several pairs of eyes will
> look at
> > > the PR and agree that it should be merged. For example, say, we need N
> +1s
> > > and zero -1s for any changes that affect those parts... (the value of N
> > > will need discussion but that is a subject for another day).
> > >
> > > So, how will we keep track of approvals? I assume that GitHub has a
> built
> > > in mechanism for this purpose?
> > >
> > > Nathan
> >
>

Re: [nuttx] Wiki Backup

[Alin Jerpelea]

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: dev@nuttx.apache.org
> Subject: Re: [nuttx] Wiki Backup
>
> Did another major round of updates.  I removed a few pages that just linked
> to documentation pages that are already linked in the documentation
> section.  We need to figure out what to do with what is in the
> documentation section.
> For PDFs and the like we can just attach them to the Documentation page and
> then link them in the individual pages, but for the HTML if is a pain to
> render the images as well.  I did a hack on the graphics one to replace the
> image url, but it is not ideal.
>
> There are also places like this where there is a link to download, and that
> should be replaced with an attachment.
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629542
>
> You can also use click Page Info to view all the external links for a
> page.  For example there is a nuttx.org and three youtube links here
> https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=139629542
>
> Also about the long URLs Confluence also will generate the short link:
>
> https://cwiki.apache.org/confluence/x/5pNSC
>
>
> There are some pages where the import did some goofy things like putting
> each line of a code block it its own block, but it is very rare and still
> readable.
>
> If others want to help review and fix formatting please do.
>
> Justin, I'll ask INFRA if they can fix the space name.
>
> Thanks,
> Brennan
> 
>
> On Mon, Dec 16, 2019 at 12:12 PM David Sidrane 
> wrote:
>
> > Brennan,
> >
> > I bet it was grueling. Thank you again Brennan!
> >
> > David
> > -Original Message-
> > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > Sent: Monday, December 16, 2019 7:50 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: [nuttx] Wiki Backup
> >
> > Greg and David,
> > The page names just need to finish getting updated, I did about 80% of
> > them. I can finish that today, I just needed to go to sleep last night.
> > Manually clicking through all the pages was grating on me.
> >
> > --Brennan
> >
> > On Mon, Dec 16, 2019, 3:21 AM David Sidrane 
> > wrote:
> >
> > > Brennan,
> > >
> > > Thank you for your efforts!
> > >
> > > Justin: Is there an issue with adding all the PPMC to have the ability
> > > to
> > > edit the content?
> > >
> > > I see some naming that looks like url id became the Page Title:
> > >
> > >  For example: NuttX Initialization Sequence is listed under
> Initsequence
> > >
> > > https://cwiki.apache.org/confluence/display/NUTTXTEST/Initsequence
> > >
> > > Also is there a way to maintain the original authors?
> > >
> > > David
> > >
> > > -Original Message-
> > > From: Brennan Ashton [mailto:bash...@brennanashton.com]
> > > Sent: Sunday, December 15, 2019 11:16 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: [nuttx] Wiki Backup
> > >
> > > Ok,
> > > That was a bigger hassle than I expected.  The converter tool was
> > > getting
> > > tripped up with odd escaping and generating bad XML files for
> > > confluence,
> > > but I think it is good now.
> > > I also went through and manually cleaned the naming, obvious issues,
> and
> > > inserted a bunch of confluence macros on the pages.
> > >
> > > https://cwiki.apache.org/confluence/display/NUTTXTEST/Nuttx
> > >
> > > I think it is good to go live, but there are a few things to address:
> > > 1) There are some links that were not wiki links, but url links to the
> > > wiki
> > > that did not get converted.  I have the sources to find all of these,
> so
> > I
> > > will tackle that soon.
> > > 2a) The documentation pages are embedding the HTML documentation that
> is
> > > on
> > > nuttx.org/Documentation but once the code is moved to github/apache I
> > will
> > > update to pull the latest.
> > > 2b) The documentation is using favicons internally as images, this is
> > > not
> > > valid and causes issues broken image links.  This should be fixed in
> the
> > > code no changes are needed on the wiki.
> > > 3) The presentations are linked to pdfs at nuttx.org Those PDFs should
> > > just
> > > become attachments to wiki pages.
> > >
> > > Justin if you move this to NUTTX from NUTTXTEST please add me to the
> > > permissions on that space as well.
> > >
> > > Thanks,
> > > Brennan
> > >
> > > On Sun, Dec 15, 2019 at 4:27 PM Gregory Nutt 
> > wrote:
> > >
> > > >
> > > > > First stab at the import went surprisingly well.  All but a few
> > > > > pages
> > > > > converted, unfortunately the hierarchy did not convert correctly so
> > > > > I
> > > > will
> > > > > have to mess with it more (these tools are mostly abandoned for 8+
> > > years
> > > > so
> > > > > at least they run).
> > > > That is good news.
> > > > > 

Re: Atomic git tagging (was RE: Project Emails)

[Alin Jerpelea]

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 Fri, Dec 13, 2019 at 10:12 AM David Sidrane 
wrote:

> Greg,
>
> I think the below steps will do a an atomic tag/branch (Branch protections
> may be needed as well)
>
> However, it exemplifies why Submodules are evil but useful.  A much simpler
> approach is 2 folder is the same project - I am aware of ALL the arguments
> -
> I agree with most of them but there are dependency on nuttx to apps from
> all
> the defconfig files and nsh)
>
> First question I would poll the community is: "How many of you do not use
> the apps folder?"
>
> --
>
> NuttX  - is the Knot repo.
> Apps is a sub module
> Nuttx is a sub module
>
> origin is the remote for NuttX, apps and nuttx
>
> cd NuttX
> git checkout master
> git submodule sync --recursive && git submodule update --init --recursive
>
> git checkout -b master_imx_network_fixes
> cd nuttx
> git checkout -b master_imx_network_fixes
> cd ../apps
> git checkout -b master_imx_network_fixes
>
> cd ../nuttx
> Do all your changes.
> git add ...
> git commit  ...
> git push origin master_imx_network_fixes
>
> cd ../apps
> Do all your changes.
> git add ...
> git commit  ...
> git push origin master_imx_network_fixes
>
> cd .. (NuttX)
> git add apps nuttx
> git commit  ...
>
> git tag -a nuttx-yada -m "my version 1.4"
> git push origin nuttx-yada
> 
>
>
> David
>
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Thursday, December 12, 2019 7:05 PM
> To: dev@nuttx.apache.org
> Subject: Re: Project Emails
>
>
> > How about sub modules? We atomically tag across both to keep the project
> > in
> > proper synchronization.
>
> Some of these things are difficult to discuss at this point in time
> because we not have enough Apache knowledge and experience. What I have
> seen from following the release emails is the release will go through
> several release candidates before before a final release is made.
> Tagging releases as NuttX did in the past won't support that.  I believe
> that you would have to use branches to support a series of release
> candidates until the release is made (and perhaps even to support
> further releases on the branch for bug fixes).
>
> We can't really branch across sub-modules, can we?  I think we need to
> know much more before we could take any clear position on this.
>
> Greg
>