On Sun, Mar 8, 2020 at 5:43 PM Gregory Nutt wrote:
> Only slightly related... This morning, I removed some of the writing
> instructions from the trop draft work flow proposal. I think they have
> served their purpose and destroy readability of the document. I also
> delete all of the comments t
If we go back to my original email on this subject a couple of months ago,
I suggested to begin with a tl;dr; section and then follow it with the
detailed text. Now that we have the detailed text, it's a simple matter to
summarize it and put the summary at the top.
Only slightly related... Th
On Fri, Mar 6, 2020 at 10:20 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:
> I think you made it clear that you prefer a TL;DR; document. Maybe we
> can have both.
If we go back to my original email on this subject a couple of months ago,
I suggested to begin with a tl;dr; se
--Original Message-
> From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> Sent: Friday, March 06, 2020 3:30 AM
> To: dev@nuttx.apache.org
> Subject: Re: squashing commits or not
>
> > Thank you. The link did not lad me and I have no idea what to look at
>
s time to renovate!
David
-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Friday, March 06, 2020 3:30 AM
To: dev@nuttx.apache.org
Subject: Re: squashing commits or not
> Thank you. The link did not lad me and I have no idea what to look a
@gmail.com]
> Sent: Thursday, March 05, 2020 10:41 AM
> To: dev@nuttx.apache.org
> Subject: Re: squashing commits or not
>
> > How about clear to the point work steps? Do we have the interim workflow
> > listed anywhere that it can be read, without the diatribes?
>
> I ju
ur "best engineering judgment" to educate the group, you
> know,
> Share the knowledge help the community, help the project
>
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Thursday, March 05, 2020 9:25 AM
> To: dev@nuttx.a
I just wrote something really quickly. Maybe you want to take a look [1]
We can add to that section more information on how to squash WIP
commits using interactive rebasing.
I'll come back later to do more. But I need to go. Feel free to edit.
1.
https://cwiki.apache.org/confluence/display/NU
Why would you merge it to branch it is not ready?
There is no way to know if it is not ready. There is no CI for PRs now.
You have to merge first, then you can see if it is ready.
Let's not confuse what-I-am-doing-now with the final workflow which is
NOT defined, NOT approved, and NOT in
eering judgment" to educate the group, you know,
> Share the knowledge help the community, help the project
>
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Thursday, March 05, 2020 9:25 AM
> To: dev@nuttx.apache.org
> Subject: Re:
build make checks it and ask to
install it)
The problem solved by workflow and tools.
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, March 05, 2020 9:32 AM
To: dev@nuttx.apache.org
Subject: Re: squashing commits or not
One big problem that I encounter
, you know,
Share the knowledge help the community, help the project
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, March 05, 2020 9:25 AM
To: dev@nuttx.apache.org
Subject: Re: squashing commits or not
No one gets to set any rules. No one gets to e
One big problem that I encounter is that people change .c and .h files
but do not run nxstyle against the resulting files. It is not really
possible to verify that online (currently, hopefully soon, however). So
you don't know about the stylistic problems until you have already
merged onto a
No one gets to set any rules. No one gets to enforce any rules.
Committers are free to do what they choose. That is the Apache way: It
is anarchy held together by a belief in common principles and a project
culture. If you can't trust people to do that job, you are working on
the wrong proj
If you have clear work steps for a rebase work flow (prior to review).
Contributors can and will do PR hygiene.
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, March 05, 2020 9:20 AM
To: dev@nuttx.apache.org
Subject: Re: squashing commits or not
>
If you do have a PR with B1 and B2 commits and generates in master:
A1 <- B1 <- B2 <- C1 <- master
If B1 and B2 are part of the same change, I would probably use git
rebase -i to squash only those two
inal Message-
> From: Miguel Ángel Herranz [mailto:mig...@midokura.com.INVALID]
> Sent: Thursday, March 05, 2020 8:16 AM
> To: dev@nuttx.apache.org
> Subject: Re: squashing commits or not
>
> Why not just leave all the commits and generate on master a single merge
> commit?
>
&
commits or not
We have to trust that committers will do the best job that they can. We
have no control over how committers do that job. There is no mechanism
for such control. This is an area where there is no option but to trust
the judgement of the committers.
Discussing good practice is fine
Isn't that is just more noise?
-Original Message-
From: Miguel Ángel Herranz [mailto:mig...@midokura.com.INVALID]
Sent: Thursday, March 05, 2020 8:16 AM
To: dev@nuttx.apache.org
Subject: Re: squashing commits or not
Why not just leave all the commits and generate on master a single
Why not just leave all the commits and generate on master a single merge
commit?
In git CLI you can easily filter the non-merge commits using `git log
--merges` (same sequence as squashed PR) and then inspect the involved
commits looking at the non-master commit parent.
Not sure if the problem is
We have to trust that committers will do the best job that they can. We
have no control over how committers do that job. There is no mechanism
for such control. This is an area where there is no option but to trust
the judgement of the committers.
Discussing good practice is fine, but there
On Thu, Mar 5, 2020 at 10:22 PM Gregory Nutt wrote:
>
> The decision to squash or not will be left to the best judgement of the
> committer.
Yes, committer could give the suggestion, or even decline the PR, but
it isn't good practice to directly do squash without any discussion.
Even worse, commi
The decision to squash or not will be left to the best judgement of the
committer.
On Thu, Mar 5, 2020 at 7:58 PM Abdelatif Guettouche
wrote:
>
> > Because if
> > the contributor take the time to split the change into serveral small
> > patch, which mean it's valuable to do so.
>
> I agree, but this isn't always the case.
> It is okay to have PRs with multiple commits, as you me
: squashing commits or not
> Because if
> the contributor take the time to split the change into serveral small
> patch, which mean it's valuable to do so.
I agree, but this isn't always the case.
It is okay to have PRs with multiple commits, as you mentioned, we can
even reques
> Because if
> the contributor take the time to split the change into serveral small
> patch, which mean it's valuable to do so.
I agree, but this isn't always the case.
It is okay to have PRs with multiple commits, as you mentioned, we can
even request to do so.
However, some of the commits are j
On Thu, Mar 5, 2020 at 5:10 PM Abdelatif Guettouche
wrote:
>
> Hi,
>
> We do not squash commits unless they are related (Which should have been
> done by the OP in the firsr place).
But even the patch related each other, it's better to keep the
individual small patch instead merging into one big
Hi,
We do not squash commits unless they are related (Which should have been
done by the OP in the firsr place).
We actually encourage putting unrelated changes in separate commits.
On Thu, Mar 5, 2020, 05:26 Takashi Yamamoto
wrote:
> hi,
>
> it seems that in nuttx it's common to squash commi
28 matches
Mail list logo
