Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Duo Zhang]

Xiang Xiao  于2019年12月25日周三 下午1:36写道：

> Yes, I agree that we shouldn't make the workflow too hard to scare
> people for contribution.
> NuttX isn't a new project, it's open source for more than ten years
> and has a mature workflow, the whole community is already familiar
> with it.
> Let me summary the current workflow:
> 1.User send patch against master to
> https://groups.google.com/forum/#!forum/nuttx or
> 2.User send PR against master to
> https://bitbucket.org/nuttx/nuttx/src/master/
> 3.Greg review and merge the change to master(with some modification if
> needed)
> 4.Greg make a official release and create a tag to mark the point
> every two(or three?) months
> To "be apache way", the required change is only item 3&4: all
> committer need involve the reviewing and release process.
> So, I suggest that we adapter the current workflow with as minimal
> changes as possible:
> 1.User send patch against master to dev@nuttx.apache.org or
> 2.User send PR against master to https://github.com/apache/incubator-nuttx
> 3.Committer review and merge the change to master(with some
> modification if needed)
> 4.Committer make a official release and create a tag to mark the point
> every two(or three?) months
> We only need to disscuss how committer review the change and make the
> release.
> Since we have two month for the next release, let's focus on the
> review process in this time.
> Here are some questions I have, other may add more:
> a.How many committers need approve the patch before it can merge?
>
Usually one committer is enough, the only different is that, if the patch
is proposed by a committer, then you need another committer to approve it.
We need to make sure that a patch has to be reviewed by a committer other
than the author.

> b.How much time give the committer the chance to say no?
>
This depends. In general, if a committer thinks it is fine to merge then it
can merge the patch/PR. But other committers have the rights to revert the
patch/PR, for example if you are not an expert of this area but he/she is,
and you even do not ask for his/her comments. So I think
during collaboration, you will find the suitable way to decide whether it
is OK to merge a PR. We do not need to define everything explicitly.

> Once all questions get the resonable answer, we can make a vote.
> If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> backport, LTS) send your proprosal to dev list and let community
> discuss and vote.
> But before the proprosal is accepted by the community, why we stop to
> use the current workflow and make our work stuck?
>
> Thanks
> Xiang
>
> On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > Some observations that might apply.
> >
> > I've used GitFlow on a few projects here at Apache and elsewhere, it
> does have some downsides, it’s overly complex and confuses beginners
> (particularly those unfamiliar with git),tends to create long lived
> branches (which are hard to merge), master and develop (or whatever you
> call the main two branches) tend to subtly get out of sync over time.
> >
> > You can change the GitHub default branch (you need to ask infra). A
> bigger issue with having master / develop and if you don’t merge frequently
> is that people don’t think the committers are that active, external people
> don't tend to look at activity on the branches.
> >
> > Note that Apache Git/GitHub has some restrictions, we don’t want history
> to be rewritten for legal and provenance reasons so a couple of things you
> may be used to doing outside of Apache may not be possible. Squashing
> commits in some projects tends to be frowned on for this reasons. Similarly
> we need to know the author of any change.
> >
> > Thanks,
> > Justin
> >
> >
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Xiang Xiao]

Yes, I agree that we shouldn't make the workflow too hard to scare
people for contribution.
NuttX isn't a new project, it's open source for more than ten years
and has a mature workflow, the whole community is already familiar
with it.
Let me summary the current workflow:
1.User send patch against master to
https://groups.google.com/forum/#!forum/nuttx or
2.User send PR against master to https://bitbucket.org/nuttx/nuttx/src/master/
3.Greg review and merge the change to master(with some modification if needed)
4.Greg make a official release and create a tag to mark the point
every two(or three?) months
To "be apache way", the required change is only item 3&4: all
committer need involve the reviewing and release process.
So, I suggest that we adapter the current workflow with as minimal
changes as possible:
1.User send patch against master to dev@nuttx.apache.org or
2.User send PR against master to https://github.com/apache/incubator-nuttx
3.Committer review and merge the change to master(with some
modification if needed)
4.Committer make a official release and create a tag to mark the point
every two(or three?) months
We only need to disscuss how committer review the change and make the release.
Since we have two month for the next release, let's focus on the
review process in this time.
Here are some questions I have, other may add more:
a.How many committers need approve the patch before it can merge?
b.How much time give the committer the chance to say no?
Once all questions get the resonable answer, we can make a vote.
If anyone has a new idea(e.g. submodule, dev/pr/release branch,
backport, LTS) send your proprosal to dev list and let community
discuss and vote.
But before the proprosal is accepted by the community, why we stop to
use the current workflow and make our work stuck?

Thanks
Xiang

On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean  wrote:
>
> Hi,
>
> Some observations that might apply.
>
> I've used GitFlow on a few projects here at Apache and elsewhere, it does 
> have some downsides, it’s overly complex and confuses beginners (particularly 
> those unfamiliar with git),tends to create long lived branches (which are 
> hard to merge), master and develop (or whatever you call the main two 
> branches) tend to subtly get out of sync over time.
>
> You can change the GitHub default branch (you need to ask infra). A bigger 
> issue with having master / develop and if you don’t merge frequently is that 
> people don’t think the committers are that active, external people don't tend 
> to look at activity on the branches.
>
> Note that Apache Git/GitHub has some restrictions, we don’t want history to 
> be rewritten for legal and provenance reasons so a couple of things you may 
> be used to doing outside of Apache may not be possible. Squashing commits in 
> some projects tends to be frowned on for this reasons. Similarly we need to 
> know the author of any change.
>
> Thanks,
> Justin
>
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Justin Mclean]

Hi,

> The style fix should be in one patch not the separated patch. If the
> new code has the style problem, contributor should fix it and resend
> PR again.

While generally if you broke something (like a build) you should be the one to 
fix it, it’s more encouraging to help out new contributors. In some cases that 
may mean a committer or PMC member needs to fix a patch to show them what to do 
in future patches. The users and contributors should be your primary focus. 
Telling someone to jump through hoops they don’t understand may drive them 
away, helping them understand what required for future patches/PRs is often 
better. A poor quality patch can be better than no patch at all, as it may 
contain a great idea or an important fix, people can collaborate and fine tune 
it and fix it before it is committed / merged.

> Nobody has the right bypass the criticia we will define in the
> workflow document and merge the patch(even it just fix the style
> issue) directly.

Like all guidelines there may be some cases, when this needs to be bypassed e.g 
urgent security issue or broken build. It certainly should come with a good 
explanation to why this was needed, but it's better to follow good guideline 
than have absolute rules.

Thanks,
Justin

Re: Why the text displayed by SSD1306 / I2C is reversed along the vertical axis

[Nii Jyeni]

Hi～
I tried setting the CONFIG_LCD_PORTRAIT and CONFIG_LCD_RPORTRAIT options, but 
the SSD1306 does not seem to support these two options. CONFIG_LCD_RLANDSCAPE 
is used, but it just flips the original image horizontally, and the characters 
do not return to the normal display direction.
Please forgive me as a newbie, what is IIRC? I didn't find the corresponding 
option in the configuration menu. Can you say more details?
BR
NiiJyeni

> 2019年12月24日 下午4:48，Sebastien Lorquet  写道：
> 
> hello
> 
> IIRC the config menus allow you to flip the display direction. Did you have a
> look over there?
> 
> Sebastien
> 
> Le 24/12/2019 à 08:39, Nii Jyeni a écrit :
>> Hi~
>> I am trying the graphics module of nuttx. I just used the nxtext sample 
>> program and found that the text displayed on oled is reversed. It seems that 
>> each character is flipped vertically. Does anyone know what is going on 
>> here? how should I solve this? Thank you!
>> 
>> BOARD:STM32F407VE（compatible stm32f4discovery）
>> HOST:macOS

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Justin Mclean]

Hi,

Some observations that might apply.

I've used GitFlow on a few projects here at Apache and elsewhere, it does have 
some downsides, it’s overly complex and confuses beginners (particularly those 
unfamiliar with git),tends to create long lived branches (which are hard to 
merge), master and develop (or whatever you call the main two branches) tend to 
subtly get out of sync over time.

You can change the GitHub default branch (you need to ask infra). A bigger 
issue with having master / develop and if you don’t merge frequently is that 
people don’t think the committers are that active, external people don't tend 
to look at activity on the branches.

Note that Apache Git/GitHub has some restrictions, we don’t want history to be 
rewritten for legal and provenance reasons so a couple of things you may be 
used to doing outside of Apache may not be possible. Squashing commits in some 
projects tends to be frowned on for this reasons. Similarly we need to know the 
author of any change.

Thanks,
Justin

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

I think there may be 2 schools of thought on style fixes. Imagine up  front
creating a commit before changing code in files that fixes ONLY all of the
style issues.  Essentially this commit should contain only white space
changes. If the commit is marked as such.  It can be mechanically validated
by comparing the binary result of the build Before & After the application
Of the style commit.

 The next commit in the set would have the actual changes to the code. This
is where experts in the subject matter can add value reviewing it.

Monster PRs ( Lots of files changed with lots of lines of changed) are very
difficult to review. If the majority of the changes are style only. The
above method  Reduces the possibility of error  While minimizing the burden
on subject matter experts.


On Tue, Dec 24, 2019, 6:18 PM Xiang Xiao  wrote:

> On Wed, Dec 25, 2019 at 6:52 AM Gregory Nutt  wrote:
> >
> >
> > > If they are related / dependent on each other, then I think those
> > > kinds of patchsets should be encapsulated in one branch.
> >
> > The need to be applied and committed in sequence.  Sometimes the final
> > patch is the one that fixes the coding style.  This is inherently very
> > manual.
> >
>
> The style fix should be in one patch not the separated patch. If the
> new code has the style problem, contributor should fix it and resend
> PR again.
> If the code base has the style issue, we should send new PR to fix the
> whole style issue.
>
> Of course, some committer may want to help fix the issue. It's fine,
> but the new change still need pass all check and reviewed by other
> committer before merge.
> Nobody has the right bypass the criticia we will define in the
> workflow document and merge the patch(even it just fix the style
> issue) directly.
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

I think you have landed on the very motivation behind, and the very benefit
that pull requests offer over patches. The submitter(s) is/are the one(s)
who know how the pieces fit together. It is they that are responsible for
creating something that's mergeabel. A set or PRs with a "No conflicts"
status.

Just imagine the streams of patches that come in chunks as individual PR.
If after 1 PR comes in it causes a second PR of the groups to become
conflicted. The onus is on the submitter to rebase and resolve the issues.

On past projects that I have worked on the process was to carry patches and
apply them in the build. This gave me a sense of security in that I could
see all of the deltas from upstream in the patch set.  Then other members
of the team suggested that we carry these changes as commits on top of (re
based on) upstream.  This left me totally uncomfortable because it
completely changed the why I was working. But what I learned was the key
benefit of  this methodology is that: it is far better to find the
conflicts during a rebase in a git re base session then it is to try to
decipher failed patch applications in a build. After doing it with this re
based workflow I realized  the benefits. It was super uncomfortable at 1st
but now it's 2nd nature and much, much more efficient not to mention
foolproof.

This is essentially what happens when A PR Has conflicts and the submitter
is asked to resolve them. They re base on the current master and they are
very quickly able to ensure their changes are now proper in the new context.

David

On Tue, Dec 24, 2019, 2:52 PM Gregory Nutt  wrote:

>
> > If they are related / dependent on each other, then I think those
> > kinds of patchsets should be encapsulated in one branch.
>
> The need to be applied and committed in sequence.  Sometimes the final
> patch is the one that fixes the coding style.  This is inherently very
> manual.
>
>
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Duo Zhang]

I do not think it is a big deal to force the base branch for a PR. You are
free to choose the way you like, just tell users which branch to use when
creating a PR.

In ASF, like Hadoop and HBase, maser is the dev branch and by default all
PR must be created against the master branch. There are users open a PR
against other branches, then we just tell them to open a new PR against
master, and close the current one (and for hadoop, the 'master' branch is
actually called 'trunk'...). And IIRC, there are other projects in the ASF
want user to open PR against the current release branch, and the commiters
will cherry-pick the commit back to master branch.

Of course sometimes the user will just leave and not open the PR as his/her
code base is not against the master branch and he/she do not want to spend
much time on porting, that's fine. This is open source, people come and go.

In general, just start a vote and let PPMC decided the branching strategy.
And do we have a wiki page to record the discussion result? I think we'd
better reach agreement step by step, and this is good sign to the IPMC,
that we are making progress. For other things, like whether we should
squash all the commits in a PR into one when merging, or there are
dependencis between PRs, we can discuess them in another thread.

Thanks.

Brennan Ashton  于2019年12月25日周三 上午8:05写道：

> On Tue, Dec 24, 2019, 3:13 PM Gregory Nutt  wrote:
>
> >
> > >
> > >> If they are related / dependent on each other, then I think those
> > >> kinds of patchsets should be encapsulated in one branch.
> > >
> > > The need to be applied and committed in sequence.  Sometimes the final
> > > patch is the one that fixes the coding style.  This is inherently very
> > > manual.
> > They need to be merged separately too since the author is often
> > different on each patch.
> >
>
> Why does the authors matter. There is no reason a patchset or PR needs to
> be squashed into a single commit, they just should not be broken along the
> way.
>
> Also order in a patch set is usually defined by a number prefix for example
> this is how it is defined by the Linux kernel, but is inline with most
> projects that do mailing list patches.
>
>
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#the-canonical-patch-format
>
>
> There is really nothing so unique about this project that we need to get
> too creative.
>
> --Brennan
>
> >
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Xiang Xiao]

On Wed, Dec 25, 2019 at 6:52 AM Gregory Nutt  wrote:
>
>
> > If they are related / dependent on each other, then I think those
> > kinds of patchsets should be encapsulated in one branch.
>
> The need to be applied and committed in sequence.  Sometimes the final
> patch is the one that fixes the coding style.  This is inherently very
> manual.
>

The style fix should be in one patch not the separated patch. If the
new code has the style problem, contributor should fix it and resend
PR again.
If the code base has the style issue, we should send new PR to fix the
whole style issue.

Of course, some committer may want to help fix the issue. It's fine,
but the new change still need pass all check and reviewed by other
committer before merge.
Nobody has the right bypass the criticia we will define in the
workflow document and merge the patch(even it just fix the style
issue) directly.

Re: Single Committer

[Justin Mclean]

Hi,

> I don't want the job so I have no problem going back the way things were.

I'm sure you (and others) can review patches that come in, and as long as 
patches get reviewed before being committed all will be good. I would suggest 
in this transition period you allow some time and have several people to review 
each PR or patch.

Thanks,
Justin

Re: Single Committer

[Gregory Nutt]

I don't want the job so I have no problem going back the way things were.

I would ask only the we avoid controversial workflow-related commits 
until we have workflow requirements requirements in place.  We cannot 
deal with that kind of power politics while we are trying to get this 
fragile group working.  If the pain level gets that high again, I will 
have to resign myself for health reasons and save the IPMC the trouble.


With no defined workflow we actually should not take any commits or 
PRs.  There is no harm in letting them build up as backlog.


So I resign the single committer role effective immediately and may God 
help us.


Everyone enjoy the holidays.

Greg

On 12/24/2019 4:42 PM, Justin Mclean wrote:

Hi,

-1 (from me)


Recent events have made me reconsider some decisions I made.  I threw off the 
single committer mantle when I saw the abuse of privilege in the repositories.  
If the PPMC agrees to it, I will take up that role again.

I would suggest you listen to your mentors, that have mentored many projects 
and have seen the sort of issues that can occur. If the project continued down 
this path and this continued for some time without correction, the IPMC would 
ask the project to leave the ASF.


* THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
   expedite the avalanche of commits expected after the holidays.

It certainly is not and I strongly suggest that you do not go down this path.


If any of this concerns people, please "Just Say No.”

I have many concerns.


Pros:  This will provide project continuity until the PPMC is fully functional.

And this will delay them doing that.

Thanks,
Justin

Re: Single Committer

[Adam Feuer]

+1

On Tue, Dec 24, 2019 at 5:18 AM Alan Carvalho de Assis 
wrote:

> +1
>
> On Monday, December 23, 2019, Gregory Nutt  wrote:
> > Recent events have made me reconsider some decisions I made.  I threw off
> the single committer mantle when I saw the abuse of privilege in the
> repositories.  If the PPMC agrees to it, I will take up that role again.
> >
> > But let's be frank.  Here is what I think that means:
> >
> >  * I would be sole committer of changes.  The repositories would have
> >to be treated as read-only just as back in the Bitbucket days.
> >  * I would grandfather in the i.MXRT changes.
> >  * I will decline all workflow related changes until workflow
> >requirements are established (that is my only real motivation for
> >suggesting this:  To make certain that we have proper requirements
> >in place before we accept PX4 workflow into our repositories.  We
> >need to do this right and I am willing to protect the repositories
> >until the workflow requirements are established.  I expect that to
> >take about two weeks.)
> >  * I would create a dev branch and expect all PRs to be against that
> >dev branch.
> >  * As soon as the PPMC is confident that it has the processes in place
> >to handle the commit workload I will gladly relinquish this role.
> >  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
> >expedite the avalanche of commits expected after the holidays.
> >
> > If any of this concerns people, please "Just Say No."  I am not married
> to the idea and I am not forcefully advocating it.  This is what people
> wanted me to do a few days ago and if I can protect our right to define the
> workflow, then I will do it.  For me it is a sacrifice that I would take
> with no pleasure in.
> >
> > Pros:  This will provide project continuity until the PPMC is fully
> functional.  Having workflow requirements will be a huge step in that
> direction.  People stressed about the commit process can relax with
> confidence.  This will protect the code base from premature work flow
> changes until we have an understanding of what we want.  No harm is done by
> deferring workflow changes until we as a team are prepared to deal with
> them.
> >
> > Cons:  This is not the Apache way.  People who are trying to bulldoze the
> PX4 work flow into the repositories will hate the idea.  Mentors will hate
> the idea.  An approach more consistent with the Apache way would just be to
> let the chaos prevail.  That is fine with me too as long as we do not let
> PX4 advocates take away our group right to define our own workflow.  We can
> still just put all workflow changes on hold until we have the requirements
> in hand.
> >
> > I am not pushing anything.  Think about it and let me know what you would
> like to do.
> >
> > Greg
> >
> >
> >
>


-- 
Adam Feuer 

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Brennan Ashton]

On Tue, Dec 24, 2019, 3:13 PM Gregory Nutt  wrote:

>
> >
> >> If they are related / dependent on each other, then I think those
> >> kinds of patchsets should be encapsulated in one branch.
> >
> > The need to be applied and committed in sequence.  Sometimes the final
> > patch is the one that fixes the coding style.  This is inherently very
> > manual.
> They need to be merged separately too since the author is often
> different on each patch.
>

Why does the authors matter. There is no reason a patchset or PR needs to
be squashed into a single commit, they just should not be broken along the
way.

Also order in a patch set is usually defined by a number prefix for example
this is how it is defined by the Linux kernel, but is inline with most
projects that do mailing list patches.

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#the-canonical-patch-format


There is really nothing so unique about this project that we need to get
too creative.

--Brennan

>

Re: Ethernet over USB on Arduino Due

[Adam Feuer]

Greg,

Thank you! I also came the same conclusion after reading the SAM3X and SAM4
manuals just now.

My next project needs USB over Ethernet on the SAMA5D27... I was just
trying to get a board that's well supported like the Arduino Due working.
But since UDP is not implemented for it, it looks like it will (might?) be
faster to get the SAMA5D36 working, and then try to get the D27 working.

Ok, I'll try debugging the SAMA5D36-Xplained configuration.

cheers
adam

On Mon, Dec 23, 2019 at 4:41 PM Gregory Nutt  wrote:

> I don't think that the SAM3X8E supports the UDP module.  Looks like it
> supports UDPHS which would be different:
> https://www.microchip.com/wwwproducts/en/ATsam3x8e#additional-features
> See also arch/arm/include/sam34/chip.h.
>
> There is a hardware/sam_udphs.h header file, but I don't see any udphs
> driver.
>
> I would say that the driver has never been implemented.
>
> There is a sama5/sam_udphs.c driver.  Perhaps that could be backported
> if the IP is the same?
>
> Greg
>
> On 12/23/2019 6:08 PM, Adam Feuer wrote:
> > Thanks Greg.
> >
> > When I manually edit the .config file and add this:
> >
> > CONFIG_SAM34_UDP=y
> >
> > Then try to make again, I get a bunch of errors for missing defines
> > (PMC_UDP, SAM_IRQ_UDP, etc.). These seem to be defined in
> > arch/arm/src/sam34/hardware/sam_pmc.h, but only for
> > CONFIG_ARCH_CHIP_SAM4S or CONFIG_ARCH_CHIP_SAM4E, not for SAM3 like
> > the Arduino Due:
> >
> >
> https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/sam34/hardware/sam_pmc.h#L212
> >
> > I tried to follow these undefined identifiers and made some changes
> > that got nuttx to compile. But when I flash nuttx.bin to the board
> > using bossac, I get a blinking RX light, which indicates a panic.
> >
> > Here's the changes I made:
> >
> >
> https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/arduino-due-ethernet-over-usb
> >
> > I guess I need to debug this too. :) Any tips? Did I do something
> > wrong with these modifications?
> >
> > cheers
> > adam
> >
> >
> > On Mon, Dec 23, 2019 at 11:43 AM Gregory Nutt  > > wrote:
> >
> > ..., but I'm down to this last missing function:
> > > void up_usbinitialize(void)
> >
> > Defined here:
> >
> > $ grep -r up_usbinitialize arch/arm/src/sam34
> > arch/arm/src/sam34/sam_udp.c: * Name: up_usbinitialize
> > arch/arm/src/sam34/sam_udp.c:void up_usbinitialize(void)
> > arch/arm/src/sam34/sam_udp.c:   * in when up_usbinitialize() was
> > first
> > called.
> >
> > Sound like a configuration problem:
> >
> >
> > 146 ifeq ($(CONFIG_SAM34_UDP),y)
> > 147 CHIP_CSRCS += sam_udp.c
> > 148 endif
> >
> >
> >
> > --
> > Adam Feuer mailto:a...@starcat.io>>
>


-- 
Adam Feuer 

Re: problem booting NuttX on SAMA5D3-Xplained

[Adam Feuer]

Greg,

Ok, I can boot the SAMA5D3-Xplained board to the NuttX shell using the
procedure you outlined! (Loading the nuttx binary into RAM using the J-Link
debugger.) Thank you! Super! NSH is accessible via the DBGU port.

I'll try the same procedure on the SAMA5D2-XULT board either tomorrow or in
the next few days.

Now... to figure out how go get the D3 board to boot from flash or the SD
Card. :) I will try to follow the README file.

Thank you so much!

cheers
adam

On Sun, Dec 22, 2019 at 9:32 PM Gregory Nutt  wrote:

> > Make sure you compile with debug info enabled and no optimization.
> Then, since you mentioned you have a Segger J-Link JTAG probe, I highly
> recommend you use Segger’s debugger Ozone (free J-Link probes) — you’ll be
> able to easily single-step and determine what’s going wrong…
>
> If you have a J-Link then you are in business and it shouldn't be
> difficult to find the problem.  You can use the J-Link like this:
>
>   * Start U-Boot and break out to the prompt.  This will initialize the
> SDRAM.
>   * Then load NuttX in SDRAM and debug it.
>
> The first think I would want to know is does the code get to nsh_main().
>
>   * gdb> file nuttx
>   * gdb > b nsh_main
>   * gdb> mon reset
>   * gdb> c
>
> If you get there, then all of the initialization went OK.  Then put a
> breakpoint on fputs().  You should hit it via
>
> nsh_session.c:  fputs(g_nshgreeting, pstate->cn_outstream);
>
> If you get there then it is at least trying to get something on the
> serial console, but is failing for some reason:  maybe wrong UART or
> wrong pin configuration.
>
>
>

-- 
Adam Feuer 

Re: Ethernet over USB on Arduino Due

[Adam Feuer]

Thanks Greg.

When I manually edit the .config file and add this:

CONFIG_SAM34_UDP=y

Then try to make again, I get a bunch of errors for missing defines
(PMC_UDP, SAM_IRQ_UDP, etc.). These seem to be defined in
arch/arm/src/sam34/hardware/sam_pmc.h, but only for CONFIG_ARCH_CHIP_SAM4S
or CONFIG_ARCH_CHIP_SAM4E, not for SAM3 like the Arduino Due:

https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/sam34/hardware/sam_pmc.h#L212

I tried to follow these undefined identifiers and made some changes that
got nuttx to compile. But when I flash nuttx.bin to the board using bossac,
I get a blinking RX light, which indicates a panic.

Here's the changes I made:

https://github.com/apache/incubator-nuttx/compare/master...adamfeuer:feature/arduino-due-ethernet-over-usb

I guess I need to debug this too. :) Any tips? Did I do something wrong
with these modifications?

cheers
adam


On Mon, Dec 23, 2019 at 11:43 AM Gregory Nutt  wrote:

> ..., but I'm down to this last missing function:
> > void up_usbinitialize(void)
>
> Defined here:
>
> $ grep -r up_usbinitialize arch/arm/src/sam34
> arch/arm/src/sam34/sam_udp.c: * Name: up_usbinitialize
> arch/arm/src/sam34/sam_udp.c:void up_usbinitialize(void)
> arch/arm/src/sam34/sam_udp.c:   * in when up_usbinitialize() was first
> called.
>
> Sound like a configuration problem:
>
>
> 146 ifeq ($(CONFIG_SAM34_UDP),y)
> 147 CHIP_CSRCS += sam_udp.c
> 148 endif
>
>

-- 
Adam Feuer 

Re: Single Committer

[Justin Mclean]

Hi,

-1 (from me)

> Recent events have made me reconsider some decisions I made.  I threw off the 
> single committer mantle when I saw the abuse of privilege in the 
> repositories.  If the PPMC agrees to it, I will take up that role again.

I would suggest you listen to your mentors, that have mentored many projects 
and have seen the sort of issues that can occur. If the project continued down 
this path and this continued for some time without correction, the IPMC would 
ask the project to leave the ASF.

> * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>   expedite the avalanche of commits expected after the holidays.

It certainly is not and I strongly suggest that you do not go down this path.

> If any of this concerns people, please "Just Say No.” 

I have many concerns.

> 
> Pros:  This will provide project continuity until the PPMC is fully 
> functional.

And this will delay them doing that.

Thanks,
Justin

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Gregory Nutt]

If they are related / dependent on each other, then I think those
kinds of patchsets should be encapsulated in one branch.


The need to be applied and committed in sequence.  Sometimes the final 
patch is the one that fixes the coding style.  This is inherently very 
manual.
They need to be merged separately too since the author is often 
different on each patch.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Gregory Nutt]

If they are related / dependent on each other, then I think those
kinds of patchsets should be encapsulated in one branch.


The need to be applied and committed in sequence.  Sometimes the final 
patch is the one that fixes the coding style.  This is inherently very 
manual.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman]

On Tue, Dec 24, 2019 at 3:44 PM Gregory Nutt  wrote:
> Many branches would be awkward on patch sets that consist of a dozen or
> so individual patches that cannot be squashed together because they have
> different authors.  We get lots of large patch sets from Xiaomi like
> that.  To make things more complex, there is an ordering in which the
> patches must be apply.  A given patch may not apply until a preceding
> patch by a different author is first merged.

If they are related / dependent on each other, then I think those
kinds of patchsets should be encapsulated in one branch.

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Brennan Ashton]

>
>
>
>
> Git's claim to fame is supposed to be the cheapness of branches. What if
> each PR becomes its own branch and then it either: (a) gets worked on, (b)
> applied to master, or (c) deleted?
>

As I have already said PRs automatically are branches in GitHub even if
they are not shown in the GitHub UI (why would they, they are shown as a PR)


https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally

--Brennan

>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

It is OK

Look at microsoft/vscode

58,891 commits
 360 branches
 0 packages
 145 releases
 1,048 contributors
 MIT

The pr-branches are deleted on merge.
The relasease branches foreverever
WIP branches are there until merged, or superseded.

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Tuesday, December 24, 2019 12:44 PM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)


> Git's claim to fame is supposed to be the cheapness of branches. What if
> each PR becomes its own branch and then it either: (a) gets worked on, (b)
> applied to master, or (c) deleted?

I think that would work fine.  We need to verify that we can actually
change the PR base, but if so that would keep things more independent.

Perhaps it could help us with patches where sometimes there are patches
that depend on each other or interact with other because they modify the
same area of code.  Using git to help merge patches would be easier if
the patches were on different branches.

We would probably need some encoding of branch names to associate them
with patches or PRs.

Many branches would be awkward on patch sets that consist of a dozen or
so individual patches that cannot be squashed together because they have
different authors.  We get lots of large patch sets from Xiaomi like
that.  To make things more complex, there is an ordering in which the
patches must be apply.  A given patch may not apply until a preceding
patch by a different author is first merged.

The number should not be a big concern.  Over time, we will end up with
100's of branches eventually.  Each release will probably have to be on
a branch.

Greg

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Gregory Nutt]

Git's claim to fame is supposed to be the cheapness of branches. What if
each PR becomes its own branch and then it either: (a) gets worked on, (b)
applied to master, or (c) deleted?


I think that would work fine.  We need to verify that we can actually 
change the PR base, but if so that would keep things more independent.


Perhaps it could help us with patches where sometimes there are patches 
that depend on each other or interact with other because they modify the 
same area of code.  Using git to help merge patches would be easier if 
the patches were on different branches.


We would probably need some encoding of branch names to associate them 
with patches or PRs.


Many branches would be awkward on patch sets that consist of a dozen or 
so individual patches that cannot be squashed together because they have 
different authors.  We get lots of large patch sets from Xiaomi like 
that.  To make things more complex, there is an ordering in which the 
patches must be apply.  A given patch may not apply until a preceding 
patch by a different author is first merged.


The number should not be a big concern.  Over time, we will end up with 
100's of branches eventually.  Each release will probably have to be on 
a branch.


Greg

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

The Aha moment has arrived - You got - What is your github name?

-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Tuesday, December 24, 2019 12:28 PM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

On Tue, Dec 24, 2019 at 3:15 PM Gregory Nutt  wrote:

>
> >> Also, is there a way to take a PR against master and apply it as a
> >> branch?
> >
> > I generally do that by taking the PR as a patch, then applying the
> > patch on a branch.
> >
> > But it looks like you can do that with github:
> >
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request
> >
> We will need to experiment with that, but if it works then we could
> continue to use the dev branch with no PR problems.  If we get a PR on
> master, we could just change the base to dev.
>
> That, of course, depends on keeping dev fairly clean and freshly rebased
> to master.  If things are going to linger on dev, we should move them to
> another branch.


Git's claim to fame is supposed to be the cheapness of branches. What if
each PR becomes its own branch and then it either: (a) gets worked on, (b)
applied to master, or (c) deleted?

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Gregory Nutt]

I think we should strive to keep master as close to "releasable" as
possible at all times, do development on dev branch(es), and create release
branches to which changes are only made by backporting from master. I think
this is closer to a CI/CD (Continuous Integration / Continuous Delivery)
style.


I tend to agree with, especially if we have the ability to change the 
base of PRs against master to dev.  To me, that would solve any 
usability problems with keeping master the master and dev the 
development branch.


I agree with your other points as well.  There have been a couple of 
times where I downloaded applications sources and built them on master 
assuming that is the correct place... why wouldn't it be? Then finding 
that they do not work and that you really have to build on some branch.  
It would be best for every one if we didn't have to make things any more 
complex for the end-user.


Greg

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman]

On Tue, Dec 24, 2019 at 3:15 PM Gregory Nutt  wrote:

>
> >> Also, is there a way to take a PR against master and apply it as a
> >> branch?
> >
> > I generally do that by taking the PR as a patch, then applying the
> > patch on a branch.
> >
> > But it looks like you can do that with github:
> >
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request
> >
> We will need to experiment with that, but if it works then we could
> continue to use the dev branch with no PR problems.  If we get a PR on
> master, we could just change the base to dev.
>
> That, of course, depends on keeping dev fairly clean and freshly rebased
> to master.  If things are going to linger on dev, we should move them to
> another branch.


Git's claim to fame is supposed to be the cheapness of branches. What if
each PR becomes its own branch and then it either: (a) gets worked on, (b)
applied to master, or (c) deleted?

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman]

On Tue, Dec 24, 2019 at 9:47 AM Gregory Nutt  wrote:

> That would simplify accepting PRs since the uniformed will probably
> continue to submit against master.  This would make that behavior
> workable.  Semantically, I would have to wrap my head around the notion
> that the master is not the master but a development branch.  But even
> old dogs can learn new tricks with enough time.


On the issue of whether master should be a dev branch or not, my 2 cents:

I think we should strive to keep master as close to "releasable" as
possible at all times, do development on dev branch(es), and create release
branches to which changes are only made by backporting from master. I think
this is closer to a CI/CD (Continuous Integration / Continuous Delivery)
style.

Why we would want that:

(1)
I think most users will assume that master should be buildable and usable.

(2)
If master is buildable and usable at all times, it will probably get wider
testing and therefore any new problems should be detected quickly. (Case in
point: I caught a few issues the same day they were introduced by using
master every day.)

(3)
If master becomes a dumping ground for any changes and then we have to sift
through them to decide what to port to a stable branch, it might become a
mess. I think it's best to review before it comes into the tree, and then
if approved, bring it in decisively.

Just food for (collective) thought.

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Gregory Nutt]

Also, is there a way to take a PR against master and apply it as a 
branch?


I generally do that by taking the PR as a patch, then applying the 
patch on a branch.


But it looks like you can do that with github: 
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request


We will need to experiment with that, but if it works then we could 
continue to use the dev branch with no PR problems.  If we get a PR on 
master, we could just change the base to dev.


That, of course, depends on keeping dev fairly clean and freshly rebased 
to master.  If things are going to linger on dev, we should move them to 
another branch.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Gregory Nutt]

Also, is there a way to take a PR against master and apply it as a branch?


I generally do that by taking the PR as a patch, then applying the patch 
on a branch.


But it looks like you can do that with github: 
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman]

On Tue, Dec 24, 2019 at 9:47 AM Gregory Nutt  wrote:

>
> I have some doubts:  If an an end-user clones or forks the change, it
> would still default to creating only the master branch.  You would not
> want users working on the master branch, you would want them to be
> working in the stable branch.  There could potentially bad changes on
> the master.


I haven't yet studied what David wrote in response, but I just wanted to
say:

This is why, in the Confluence workflow document, I want to spell out:
* How to obtain the code
* What steps to take before working on a PR

Namely, those steps are: to clone git and then immediately create a branch
to work on any changes. (I never code directly on master.)

If someone doesn't do that, I think we'd need to point them to that
document.

Also, is there a way to take a PR against master and apply it as a branch?

Nathan

RE:Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

Hi Greg,



I have tried to answer some of your questions. See below:



>-Original Message-
>From: Gregory Nutt [mailto:spudan...@gmail.com]
>Sent: Tuesday, December 24, 2019 6:48 AM
>To: dev@nuttx.apache.org
>Subject: Re: Software release life cycle choices could have implications
on workflow (was RE: Single Committer)





>>> An alternative way could be make master/trunk branch a dev branch and
allow

>>> all PRs to checked in, at the same time, maintain a stable branch which
you

>>> can cut release (as release manager) and pick up PRs that you carefully

>>> reviewed. - This is the Apache way and I guess can achieve the same
goal.



>That would simplify accepting PRs since the uniformed will probably

>continue to submit against master.



*[DBS] The default branch is set-able *



>This would make that behavior

>workable.  Semantically, I would have to wrap my head around the notion

>that the master is not the master but a development branch.  But even

>old dogs can learn new tricks with enough time.



>I can see how this works well into a release strategy.  But what about

>uses who want to work from clones or forks?



>I have some doubts:  If an an end-user clones or forks the change, it

>would still default to creating only the master branch.



*[DBS]  No. It is a clone\fork of ALL the branches in the repo.*



*This was a fork:*

*[image: cid:img003.jpg@01D5BA3A.F15D7100]*



>You would want users working on the master branch, you would want them to
be

>working in the stable branch.  There could potentially bad changes on

the master.



*[DBS] It is their choice to be on the Bleading edge or a stable offshoot*



*We will have give tools some special consideration because of this - a
release will have a older copy of nxstyle*



>Is there a way to force the initial branch to be the stable branch

instead of master.



*[DBS] Yes but that is not the way it should be done as the default branch
is what the PR will default against. *

*In this case development is our master and master should be the default.*



>If they make changes that they want to submit on the stable branch

>branch, it seems to me that you have essentially the same communication

>problem.  They would need to transfer their changes to the master branch

>before creating the PR.  Is that right?





*[DBS] Nope - if say we have release-nuttx-9.2.0 released branch and they
have a fix on it.*

*They have a PR against nuttx-9.2.0 (but is branch protected) We can
discuss the change and start a new branch nuttx-9.2.1-RC00 and then have
them move the PR there *

*we can do it ourselves. Pull the PR to you local repo (see githup command
line on Pr) then push to nuttx-9.2.1-RC00*

*This is the why naming matters.*



*[DBS] Most git users understand the default work flow, but a README.MD
could offer the correct*

*choice of Branches and work flow  (as can a .gitmodules when set up
correctly) but deviating from the norms*

*Is NOT a good idea as it will cause issues for everyone.*



>Another nit and this is just probably due to my fumble fingers: I often

>get weird things happening when I add changes to branches, then squash

>them into the stable branch (master in this case).



*[**DBS] Use the github in chrome (WEBUI) - it make the job simple: to
update a branch, rebase, and merge. It also has a directions to do it on
the command line correctly.*



>At that point the histories of the two branches have diverged.  I can
usually reuse the

>old branch by rebasing and pushing the branch with --force.  But the

>history will still not be 100% the same as the stable branch.  If I lose

>confidence in the content of a development branch (which is fairly

>often), I usually just delete the branch and recreate it clean.  But we

>cannot do that if master is the stable.  We can't delete master can we?

>There are ways to force to branches to be identical (in both content and

>history) but I would have to get used to doing that.



*[DBS] You can choose to use branch rebase work flow - it will be ==
[source branch] + Just your changes on top.*

*Interactively rebase it (rebase -i master and clean it up) *

*- it will dump the merge commits on your branch - we want to avoid them.*

*see mv-changes *https://github.com/MikhailGolubtsov/git-mv-changes





*Force push:*

*1) Only to your own braches (I always fetch and check the remote) or just
rebase on it.*

*2) Only on a shared branch after coordination with the team. Ask them to
push all their commit then (Do 1 above)*

* Clean it up force push. The raise the "All clear"*

*3) Never force push to master. It should be branch protected. *



>It seems that this strategy adds some nice simplifications in one area

>but at least raises some questions in others.  Perhaps GIT power users

>could answer all of those questions (but let's place not clutter up the

>list by solving the full workflow here.  Please contribute your thoughts

>directly as comments at

>
https://cwiki.apa

[GitHub] [incubator-nuttx] patacongo merged pull request #6: STM32F7 and STM32H7 SDMMC internal pull up usage fixed

[GitBox]

patacongo merged pull request #6: STM32F7 and STM32H7 SDMMC internal pull up 
usage fixed
URL: https://github.com/apache/incubator-nuttx/pull/6
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] patacongo merged pull request #7: tcp_conn: Check if the remote address is unspecified

[GitBox]

patacongo merged pull request #7: tcp_conn: Check if the remote address is 
unspecified
URL: https://github.com/apache/incubator-nuttx/pull/7
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] patacongo commented on issue #8: devif_poll_tcp_timer shouldn't be skipped in the multiple card case

[GitBox]

patacongo commented on issue #8: devif_poll_tcp_timer shouldn't be skipped in 
the multiple card case
URL: https://github.com/apache/incubator-nuttx/pull/8#issuecomment-568776573
 
 
   Correct if there is a problem.  This is a duplicate of PR 4, correct.  PR 4 
was merged via patch.  If there is more to be done.  Please let me know.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] patacongo closed pull request #8: devif_poll_tcp_timer shouldn't be skipped in the multiple card case

[GitBox]

patacongo closed pull request #8: devif_poll_tcp_timer shouldn't be skipped in 
the multiple card case
URL: https://github.com/apache/incubator-nuttx/pull/8
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] patacongo commented on issue #4: devif_poll_tcp_timer shouldn't be skipped in the multiple card case

[GitBox]

patacongo commented on issue #4: devif_poll_tcp_timer shouldn't be skipped in 
the multiple card case
URL: https://github.com/apache/incubator-nuttx/pull/4#issuecomment-568776415
 
 
   Merged via patch.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] patacongo commented on issue #4: devif_poll_tcp_timer shouldn't be skipped in the multiple card case

[GitBox]

patacongo commented on issue #4: devif_poll_tcp_timer shouldn't be skipped in 
the multiple card case
URL: https://github.com/apache/incubator-nuttx/pull/4#issuecomment-568775498
 
 
   I have already taken this change as a patch and will be merging soon.  I am 
running nxstyle against all affect files... takes awile.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request #8: devif_poll_tcp_timer shouldn't be skipped in the multiple card case

[GitBox]

xiaoxiang781216 opened a new pull request #8: devif_poll_tcp_timer shouldn't be 
skipped in the multiple card case
URL: https://github.com/apache/incubator-nuttx/pull/8
 
 
   devif_timer will be called multiple time in one period if the multiple card 
exist,
   the elapsed time calculated for the first callback is right, but the flowing 
callback
   in the same period is wrong(very short) because the global variable 
g_polltimer is
   used in the calculation.
   
   so let's pass the delay time to devif_timer and remove g_polltimer.
   
   Change-Id: I6ac3d1135e08cc0f34c51916fa713bd6e6892d04
   Signed-off-by: Xiang Xiao 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] xiaoxiang781216 closed pull request #4: devif_poll_tcp_timer shouldn't be skipped in the multiple card case

[GitBox]

xiaoxiang781216 closed pull request #4: devif_poll_tcp_timer shouldn't be 
skipped in the multiple card case
URL: https://github.com/apache/incubator-nuttx/pull/4
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] xiaoxiang781216 closed pull request #5: tcp_conn: Check if the remote address is unspecified

[GitBox]

xiaoxiang781216 closed pull request #5: tcp_conn: Check if the remote address 
is unspecified
URL: https://github.com/apache/incubator-nuttx/pull/5
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request #7: tcp_conn: Check if the remote address is unspecified

[GitBox]

xiaoxiang781216 opened a new pull request #7: tcp_conn: Check if the remote 
address is unspecified
URL: https://github.com/apache/incubator-nuttx/pull/7
 
 
   Change-Id: I6f547bb4bfb3bb621573db9097a531ce2260e794
   Signed-off-by: chao.an 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] davids5 opened a new pull request #6: STM32F7 and STM32H7 SDMMC internal pull up usage fixed

[GitBox]

davids5 opened a new pull request #6: STM32F7 and STM32H7 SDMMC internal pull 
up usage fixed
URL: https://github.com/apache/incubator-nuttx/pull/6
 
 
   
-   Code was flawed in that the Pins are defined with the
  pullups in the definition. Since there are no alterntes pins
  there is no way to remove them. So not enabling the CONFIG
  pull up did nothing as did enabling them.
   
-  This is now a compile time feature as there was no reason for
  it to be a run time. It wasted both flash and ram.
   
 - The code ignored the use of D0 for ready detection causing
  3X+ the chatter.
   
   No Internal PU and 100K External Note 2.5 us of chatter

   
![image](https://user-images.githubusercontent.com/1945821/71418551-d3f34a80-261f-11ea-990c-d4552cbaaff3.png)
   
   With Internal PU and 100K External Note 0.7 us of chatter

   
![image](https://user-images.githubusercontent.com/1945821/71418554-d6ee3b00-261f-11ea-8b4a-9d755b9b9f05.png)
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] patacongo commented on issue #5: tcp_conn: Check if the remote address is unspecified

[GitBox]

patacongo commented on issue #5: tcp_conn: Check if the remote address is 
unspecified
URL: https://github.com/apache/incubator-nuttx/pull/5#issuecomment-568768537
 
 
   I will assume that you will be unable to respond due to the time difference. 
 I will go ahead and incorporate the change as a patch to keep things moving.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] patacongo commented on issue #5: tcp_conn: Check if the remote address is unspecified

[GitBox]

patacongo commented on issue #5: tcp_conn: Check if the remote address is 
unspecified
URL: https://github.com/apache/incubator-nuttx/pull/5#issuecomment-568764365
 
 
   This is also against master.  See my comment and questions s with regard to 
PR 4.  Please advise and I will expedite the inclusion of the change.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] patacongo edited a comment on issue #4: devif_poll_tcp_timer shouldn't be skipped in the multiple card case

[GitBox]

patacongo edited a comment on issue #4: devif_poll_tcp_timer shouldn't be 
skipped in the multiple card case
URL: https://github.com/apache/incubator-nuttx/pull/4#issuecomment-568763478
 
 
   This PR is against master.  Under the current guidelines I can take only PRs 
on the dev branch.  I can take this PR as a patch from 
https://patch-diff.githubusercontent.com/raw/apache/incubator-nuttx/pull/4.patch
 and apply that to the dev branch on your behalf.  Is this acceptable to you?
   
   Alternatively, you could copy your changes to the dev and branch an submit a 
new PR.  Totally up to you.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request #5: tcp_conn: Check if the remote address is unspecified

[GitBox]

xiaoxiang781216 opened a new pull request #5: tcp_conn: Check if the remote 
address is unspecified
URL: https://github.com/apache/incubator-nuttx/pull/5
 
 
   Change-Id: I6f547bb4bfb3bb621573db9097a531ce2260e794
   Signed-off-by: chao.an 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] patacongo commented on issue #4: devif_poll_tcp_timer shouldn't be skipped in the multiple card case

[GitBox]

patacongo commented on issue #4: devif_poll_tcp_timer shouldn't be skipped in 
the multiple card case
URL: https://github.com/apache/incubator-nuttx/pull/4#issuecomment-568763478
 
 
   This PR is against master.  Under the current guidelines I can take only PRs 
on the dev branch.  I can take this PR as a patch from 
https://patch-diff.githubusercontent.com/raw/apache/incubator-nuttx/pull/4.patch
 and apply that to the dev branch on your behalf.  Is this acceptable to you?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request #4: devif_poll_tcp_timer shouldn't be skipped in the multiple card case

[GitBox]

xiaoxiang781216 opened a new pull request #4: devif_poll_tcp_timer shouldn't be 
skipped in the multiple card case
URL: https://github.com/apache/incubator-nuttx/pull/4
 
 
   devif_timer will be called multiple time in one period if the multiple card 
exist,
   the elapsed time calculated for the first callback is right, but the flowing 
callback
   in the same period is wrong(very short) because the global variable 
g_polltimer is
   used in the calculation.
   
   so let's pass the delay time to devif_timer and remove g_polltimer.
   
   Change-Id: I6ac3d1135e08cc0f34c51916fa713bd6e6892d04
   Signed-off-by: Xiang Xiao 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Gregory Nutt]

An alternative way could be make master/trunk branch a dev branch and allow
all PRs to checked in, at the same time, maintain a stable branch which you
can cut release (as release manager) and pick up PRs that you carefully
reviewed. - This is the Apache way and I guess can achieve the same goal.


That would simplify accepting PRs since the uniformed will probably 
continue to submit against master.  This would make that behavior 
workable.  Semantically, I would have to wrap my head around the notion 
that the master is not the master but a development branch.  But even 
old dogs can learn new tricks with enough time.


I can see how this works well into a release strategy.  But what about 
uses who want to work from clones or forks?


I have some doubts:  If an an end-user clones or forks the change, it 
would still default to creating only the master branch.  You would not 
want users working on the master branch, you would want them to be 
working in the stable branch.  There could potentially bad changes on 
the master.


Is there a way to force the initial branch to be the stable branch 
instead of master.


If they make changes that they want to submit on the stable branch 
branch, it seems to me that you have essentially the same communication 
problem.  They would need to transfer their changes to the master branch 
before creating the PR.  Is that right?


Another nit and this is just probably due to my fumble fingers: I often 
get weird things happening when I add changes to branches, then squash 
them into the stable branch (master in this case).  At that point the 
histories of the two branches have diverged.  I can usually reuse the 
old branch by rebasing and pushing the branch with --force.  But the 
history will still not be 100% the same as the stable branch.  If I lose 
confidence in the content of a development branch (which is fairly 
often), I usually just delete the branch and recreate it clean.  But we 
cannot do that if master is the stable.  We can't delete master can we?  
There are ways to force to branches to be identical (in both content and 
history) but I would have to get used to doing that.


It seems that this strategy adds some nice simplifications in one area 
but at least raises some questions in others.  Perhaps GIT power users 
could answer all of those questions (but let's place not clutter up the 
list by solving the full workflow here.  Please contribute your thoughts 
directly as comments at 
https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton).

[GitHub] [incubator-nuttx] patacongo merged pull request #3: Implement SO_ERROR for getsockopt()

[GitBox]

patacongo merged pull request #3: Implement SO_ERROR for getsockopt()
URL: https://github.com/apache/incubator-nuttx/pull/3
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Single Committer

[Alan Carvalho de Assis]

+1

On Monday, December 23, 2019, Gregory Nutt  wrote:
> Recent events have made me reconsider some decisions I made.  I threw off
the single committer mantle when I saw the abuse of privilege in the
repositories.  If the PPMC agrees to it, I will take up that role again.
>
> But let's be frank.  Here is what I think that means:
>
>  * I would be sole committer of changes.  The repositories would have
>to be treated as read-only just as back in the Bitbucket days.
>  * I would grandfather in the i.MXRT changes.
>  * I will decline all workflow related changes until workflow
>requirements are established (that is my only real motivation for
>suggesting this:  To make certain that we have proper requirements
>in place before we accept PX4 workflow into our repositories.  We
>need to do this right and I am willing to protect the repositories
>until the workflow requirements are established.  I expect that to
>take about two weeks.)
>  * I would create a dev branch and expect all PRs to be against that
>dev branch.
>  * As soon as the PPMC is confident that it has the processes in place
>to handle the commit workload I will gladly relinquish this role.
>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>expedite the avalanche of commits expected after the holidays.
>
> If any of this concerns people, please "Just Say No."  I am not married
to the idea and I am not forcefully advocating it.  This is what people
wanted me to do a few days ago and if I can protect our right to define the
workflow, then I will do it.  For me it is a sacrifice that I would take
with no pleasure in.
>
> Pros:  This will provide project continuity until the PPMC is fully
functional.  Having workflow requirements will be a huge step in that
direction.  People stressed about the commit process can relax with
confidence.  This will protect the code base from premature work flow
changes until we have an understanding of what we want.  No harm is done by
deferring workflow changes until we as a team are prepared to deal with
them.
>
> Cons:  This is not the Apache way.  People who are trying to bulldoze the
PX4 work flow into the repositories will hate the idea.  Mentors will hate
the idea.  An approach more consistent with the Apache way would just be to
let the chaos prevail.  That is fine with me too as long as we do not let
PX4 advocates take away our group right to define our own workflow.  We can
still just put all workflow changes on hold until we have the requirements
in hand.
>
> I am not pushing anything.  Think about it and let me know what you would
like to do.
>
> Greg
>
>
>

Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane]

>An alternative way could be make master/trunk branch a dev branch and allow
>all PRs to checked in, at the same time, maintain a stable branch which you
>can cut release (as release manager) and pick up PRs that you carefully
>reviewed. - This is the Apache way and I guess can achieve the same goal.

+1
I think because stable says what it is. Junping suggestion is an excellent
one.

I am not endorsing this tool, but it is really slick, even just to get the
concepts from the video.
(in the vedio replace `master` with `stable` with and `development` with
master)

https://blog.axosoft.com/gitflow/


Some questions to discuss as we move forward (no need for immediate
discussion)?

What will our Software release life cycle[1] look like?

Do we choose to do LTS[2]?
Do we do release branching?
Do we do backports [3] on to release candidates[1]?
Do we do hot fixes[5]?

David

[1] https://en.wikipedia.org/wiki/Software_release_life_cycle
[2] LTS is an abbreviation for “Long Term Support”.
[3] https://en.wikipedia.org/wiki/Backporting
[4]
https://softwareengineering.stackexchange.com/questions/288935/difference-between-hotfix-and-bugfix

-Original Message-
From: 俊平堵 [mailto:junping...@apache.org]
Sent: Monday, December 23, 2019 6:27 PM
To: dev@nuttx.apache.org
Subject: Re: Single Committer

bq. I would create a dev branch and expect all PRs to be against that dev
branch.
An alternative way could be make master/trunk branch a dev branch and allow
all PRs to checked in, at the same time, maintain a stable branch which you
can cut release (as release manager) and pick up PRs that you carefully
reviewed. - This is the Apache way and I guess can achieve the same goal.

Thanks,

Junping

Gregory Nutt  于2019年12月24日周二 上午8:51写道：

> Recent events have made me reconsider some decisions I made.  I threw
> off the single committer mantle when I saw the abuse of privilege in the
> repositories.  If the PPMC agrees to it, I will take up that role again.
>
> But let's be frank.  Here is what I think that means:
>
>   * I would be sole committer of changes.  The repositories would have
> to be treated as read-only just as back in the Bitbucket days.
>   * I would grandfather in the i.MXRT changes.
>   * I will decline all workflow related changes until workflow
> requirements are established (that is my only real motivation for
> suggesting this:  To make certain that we have proper requirements
> in place before we accept PX4 workflow into our repositories.  We
> need to do this right and I am willing to protect the repositories
> until the workflow requirements are established.  I expect that to
> take about two weeks.)
>   * I would create a dev branch and expect all PRs to be against that
> dev branch.
>   * As soon as the PPMC is confident that it has the processes in place
> to handle the commit workload I will gladly relinquish this role.
>   * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
> expedite the avalanche of commits expected after the holidays.
>
> If any of this concerns people, please "Just Say No."  I am not married
> to the idea and I am not forcefully advocating it.  This is what people
> wanted me to do a few days ago and if I can protect our right to define
> the workflow, then I will do it.  For me it is a sacrifice that I would
> take with no pleasure in.
>
> Pros:  This will provide project continuity until the PPMC is fully
> functional.  Having workflow requirements will be a huge step in that
> direction.  People stressed about the commit process can relax with
> confidence.  This will protect the code base from premature work flow
> changes until we have an understanding of what we want.  No harm is done
> by deferring workflow changes until we as a team are prepared to deal
> with them.
>
> Cons:  This is not the Apache way.  People who are trying to bulldoze
> the PX4 work flow into the repositories will hate the idea.  Mentors
> will hate the idea.  An approach more consistent with the Apache way
> would just be to let the chaos prevail.  That is fine with me too as
> long as we do not let PX4 advocates take away our group right to define
> our own workflow.  We can still just put all workflow changes on hold
> until we have the requirements in hand.
>
> I am not pushing anything.  Think about it and let me know what you
> would like to do.
>
> Greg
>
>
>

RE: Single Committer

[David Sidrane]

Hi Ben,

If you deep dive into this you will see that perforce is a SCM[1] that
predates git. The tools are to perforce as, github is to git.

[1] software configuration management (SCM or S/W CM)

David

-Original Message-
From: Disruptive Solutions [mailto:disruptivesolution...@gmail.com]
Sent: Monday, December 23, 2019 11:03 PM
To: dev@nuttx.apache.org
Subject: Re: Single Committer

A platform like this could help? Samsung seems to use it? Does Apache has
something like this “Helix Core” and “Swarm” ??

https://www.perforce.com/products/helix-swarm

Benefit drom these ideas? And you could start with 1 commiter and scale up
later. The way of working will be getting more clear and get to the
“standards” Greg sees??


Verstuurd vanaf mijn iPhone

> Op 24 dec. 2019 om 06:07 heeft Nathan Hartman 
> het volgende geschreven:
>
> On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt  wrote:
>>
>> Recent events have made me reconsider some decisions I made.  I threw
>> off the single committer mantle when I saw the abuse of privilege in the
>> repositories.  If the PPMC agrees to it, I will take up that role again.
>>
>> But let's be frank.  Here is what I think that means:
>>
>>  * I would be sole committer of changes.  The repositories would have
>>to be treated as read-only just as back in the Bitbucket days.
>>  * I would grandfather in the i.MXRT changes.
>>  * I will decline all workflow related changes until workflow
>>requirements are established (that is my only real motivation for
>>suggesting this:  To make certain that we have proper requirements
>>in place before we accept PX4 workflow into our repositories.  We
>>need to do this right and I am willing to protect the repositories
>>until the workflow requirements are established.  I expect that to
>>take about two weeks.)
>>  * I would create a dev branch and expect all PRs to be against that
>>dev branch.
>>  * As soon as the PPMC is confident that it has the processes in place
>>to handle the commit workload I will gladly relinquish this role.
>>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>>expedite the avalanche of commits expected after the holidays.
>>
>> If any of this concerns people, please "Just Say No."  I am not married
>> to the idea and I am not forcefully advocating it.  This is what people
>> wanted me to do a few days ago and if I can protect our right to define
>> the workflow, then I will do it.  For me it is a sacrifice that I would
>> take with no pleasure in.
>>
>> Pros:  This will provide project continuity until the PPMC is fully
>> functional.  Having workflow requirements will be a huge step in that
>> direction.  People stressed about the commit process can relax with
>> confidence.  This will protect the code base from premature work flow
>> changes until we have an understanding of what we want.  No harm is done
>> by deferring workflow changes until we as a team are prepared to deal
>> with them.
>>
>> Cons:  This is not the Apache way.  People who are trying to bulldoze
>> the PX4 work flow into the repositories will hate the idea.  Mentors
>> will hate the idea.  An approach more consistent with the Apache way
>> would just be to let the chaos prevail.  That is fine with me too as
>> long as we do not let PX4 advocates take away our group right to define
>> our own workflow.  We can still just put all workflow changes on hold
>> until we have the requirements in hand.
>>
>> I am not pushing anything.  Think about it and let me know what you
>> would like to do.
>
> I agree with this because it is premature to change the way we work
> before there is a documented workflow that helps us understand what to
> do.
>
> Over the next two weeks, we should focus on designing the top-down
> workflow. It doesn't have to be final and it doesn't have to be
> perfect. We can improve it over time. But right now it's not ready,
> so I appreciate Greg's offer to do that, while the workflow is prepared.
>
> Thanks to Greg and everyone,
> Nathan

RE: Single Committer

[David Sidrane]

+1

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Monday, December 23, 2019 11:48 PM
To: dev@nuttx.apache.org
Subject: Re: Single Committer

This makes sense giving the circumstances. It will get us going.
We can still help reviewing PRs.

On Tue, Dec 24, 2019, 08:03 Disruptive Solutions <
disruptivesolution...@gmail.com> wrote:

> A platform like this could help? Samsung seems to use it? Does Apache has
> something like this “Helix Core” and “Swarm” ??
>
> https://www.perforce.com/products/helix-swarm
>
> Benefit drom these ideas? And you could start with 1 commiter and scale up
> later. The way of working will be getting more clear and get to the
> “standards” Greg sees??
>
>
> Verstuurd vanaf mijn iPhone
>
> > Op 24 dec. 2019 om 06:07 heeft Nathan Hartman 
> het volgende geschreven:
> >
> > On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt 
> wrote:
> >>
> >> Recent events have made me reconsider some decisions I made.  I threw
> >> off the single committer mantle when I saw the abuse of privilege in
> >> the
> >> repositories.  If the PPMC agrees to it, I will take up that role
> >> again.
> >>
> >> But let's be frank.  Here is what I think that means:
> >>
> >>  * I would be sole committer of changes.  The repositories would have
> >>to be treated as read-only just as back in the Bitbucket days.
> >>  * I would grandfather in the i.MXRT changes.
> >>  * I will decline all workflow related changes until workflow
> >>requirements are established (that is my only real motivation for
> >>suggesting this:  To make certain that we have proper requirements
> >>in place before we accept PX4 workflow into our repositories.  We
> >>need to do this right and I am willing to protect the repositories
> >>until the workflow requirements are established.  I expect that to
> >>take about two weeks.)
> >>  * I would create a dev branch and expect all PRs to be against that
> >>dev branch.
> >>  * As soon as the PPMC is confident that it has the processes in place
> >>to handle the commit workload I will gladly relinquish this role.
> >>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
> >>expedite the avalanche of commits expected after the holidays.
> >>
> >> If any of this concerns people, please "Just Say No."  I am not married
> >> to the idea and I am not forcefully advocating it.  This is what people
> >> wanted me to do a few days ago and if I can protect our right to define
> >> the workflow, then I will do it.  For me it is a sacrifice that I would
> >> take with no pleasure in.
> >>
> >> Pros:  This will provide project continuity until the PPMC is fully
> >> functional.  Having workflow requirements will be a huge step in that
> >> direction.  People stressed about the commit process can relax with
> >> confidence.  This will protect the code base from premature work flow
> >> changes until we have an understanding of what we want.  No harm is
> >> done
> >> by deferring workflow changes until we as a team are prepared to deal
> >> with them.
> >>
> >> Cons:  This is not the Apache way.  People who are trying to bulldoze
> >> the PX4 work flow into the repositories will hate the idea.  Mentors
> >> will hate the idea.  An approach more consistent with the Apache way
> >> would just be to let the chaos prevail.  That is fine with me too as
> >> long as we do not let PX4 advocates take away our group right to define
> >> our own workflow.  We can still just put all workflow changes on hold
> >> until we have the requirements in hand.
> >>
> >> I am not pushing anything.  Think about it and let me know what you
> >> would like to do.
> >
> > I agree with this because it is premature to change the way we work
> > before there is a documented workflow that helps us understand what to
> > do.
> >
> > Over the next two weeks, we should focus on designing the top-down
> > workflow. It doesn't have to be final and it doesn't have to be
> > perfect. We can improve it over time. But right now it's not ready,
> > so I appreciate Greg's offer to do that, while the workflow is prepared.
> >
> > Thanks to Greg and everyone,
> > Nathan
>

Re: Why the text displayed by SSD1306 / I2C is reversed along the vertical axis

[Sebastien Lorquet]

hello

IIRC the config menus allow you to flip the display direction. Did you have a
look over there?

Sebastien

Le 24/12/2019 à 08:39, Nii Jyeni a écrit :
> Hi~
> I am trying the graphics module of nuttx. I just used the nxtext sample 
> program and found that the text displayed on oled is reversed. It seems that 
> each character is flipped vertically. Does anyone know what is going on here? 
> how should I solve this? Thank you!
>
> BOARD:STM32F407VE（compatible stm32f4discovery）
> HOST:macOS

Re: Single Committer

[Sebastien Lorquet]

Not sure throwing more tools at the current mess will fix anthing.

Full support to Greg for benevolent dictatorship extension until things are 
settled.

Sebastien

Le 24/12/2019 à 08:03, Disruptive Solutions a écrit :
> A platform like this could help? Samsung seems to use it? Does Apache has 
> something like this “Helix Core” and “Swarm” ??
>
> https://www.perforce.com/products/helix-swarm
>
> Benefit drom these ideas? And you could start with 1 commiter and scale up 
> later. The way of working will be getting more clear and get to the 
> “standards” Greg sees??
>
>
> Verstuurd vanaf mijn iPhone
>
>> Op 24 dec. 2019 om 06:07 heeft Nathan Hartman  het 
>> volgende geschreven:
>>
>> On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt  wrote:
>>> Recent events have made me reconsider some decisions I made.  I threw
>>> off the single committer mantle when I saw the abuse of privilege in the
>>> repositories.  If the PPMC agrees to it, I will take up that role again.
>>>
>>> But let's be frank.  Here is what I think that means:
>>>
>>>  * I would be sole committer of changes.  The repositories would have
>>>to be treated as read-only just as back in the Bitbucket days.
>>>  * I would grandfather in the i.MXRT changes.
>>>  * I will decline all workflow related changes until workflow
>>>requirements are established (that is my only real motivation for
>>>suggesting this:  To make certain that we have proper requirements
>>>in place before we accept PX4 workflow into our repositories.  We
>>>need to do this right and I am willing to protect the repositories
>>>until the workflow requirements are established.  I expect that to
>>>take about two weeks.)
>>>  * I would create a dev branch and expect all PRs to be against that
>>>dev branch.
>>>  * As soon as the PPMC is confident that it has the processes in place
>>>to handle the commit workload I will gladly relinquish this role.
>>>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>>>expedite the avalanche of commits expected after the holidays.
>>>
>>> If any of this concerns people, please "Just Say No."  I am not married
>>> to the idea and I am not forcefully advocating it.  This is what people
>>> wanted me to do a few days ago and if I can protect our right to define
>>> the workflow, then I will do it.  For me it is a sacrifice that I would
>>> take with no pleasure in.
>>>
>>> Pros:  This will provide project continuity until the PPMC is fully
>>> functional.  Having workflow requirements will be a huge step in that
>>> direction.  People stressed about the commit process can relax with
>>> confidence.  This will protect the code base from premature work flow
>>> changes until we have an understanding of what we want.  No harm is done
>>> by deferring workflow changes until we as a team are prepared to deal
>>> with them.
>>>
>>> Cons:  This is not the Apache way.  People who are trying to bulldoze
>>> the PX4 work flow into the repositories will hate the idea.  Mentors
>>> will hate the idea.  An approach more consistent with the Apache way
>>> would just be to let the chaos prevail.  That is fine with me too as
>>> long as we do not let PX4 advocates take away our group right to define
>>> our own workflow.  We can still just put all workflow changes on hold
>>> until we have the requirements in hand.
>>>
>>> I am not pushing anything.  Think about it and let me know what you
>>> would like to do.
>> I agree with this because it is premature to change the way we work
>> before there is a documented workflow that helps us understand what to
>> do.
>>
>> Over the next two weeks, we should focus on designing the top-down
>> workflow. It doesn't have to be final and it doesn't have to be
>> perfect. We can improve it over time. But right now it's not ready,
>> so I appreciate Greg's offer to do that, while the workflow is prepared.
>>
>> Thanks to Greg and everyone,
>> Nathan