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
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
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
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
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
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
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"
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
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
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
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
+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
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
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
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
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
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
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
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.
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
>
>
>
>
> 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
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
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
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:
> >
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
+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.
>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
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
+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
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
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
>
51 matches
Mail list logo
