This sounds like it was... clone the repo to local. Do our thing making a
feature branch.. commit to our own private repo ... Send patch (format patch)
in (after nxstyle, indent, etc and README addition) and let it reviewed by
sending it to central channel (was Google Group) and checkout
+1Singin' to choir!Sent from my Samsung Galaxy smartphone.
null
this is a simple workflow that can fit everybody
+1
On Fri, Dec 27, 2019, 22:28 Nathan Hartman wrote:
> On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao
> wrote:
> > On Fri, Dec 27, 2019 at 10:59 PM David Sidrane
> wrote:
> > > Notice what happened in the repo.
> >
> > Yes, you manually create a
On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao wrote:
> On Fri, Dec 27, 2019 at 10:59 PM David Sidrane
> wrote:
> > Notice what happened in the repo.
>
> Yes, you manually create a branch in official repo without any review process.
>
> > See
;
> David
>
> -----Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Friday, December 27, 2019 6:27 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
&
nk about the ramification. We as
> committers will not be able to use the UI when it makes sense.
>
> David
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Friday, December 27, 2019 6:27 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software re
Again, think of you are a contributor, not a commiter. Not all contributors
are committers, you should not use a different (official) workflow
comparing to them. That's my point.
Everything falls into place neatly when you consider the workflow from
the point of view of the NuttX end-user /
t;
> Now do you see why the argument makes sense?
>
> Are we going to prohibit this? Think about the ramification. We as
> committers will not be able to use the UI when it makes sense.
>
> David
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudan...@gmail.c
be able to use the UI when it makes sense.
David
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Friday, December 27, 2019 6:27 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committ
On Fri, Dec 27, 2019 at 9:26 AM Gregory Nutt wrote:
> Hi, Nathan,
>
> I remember promising to help you with the workflow document a few days
> ago. I am having a little trouble following your outline. Fleshing it
> out a little more would probably be helpful to keep us on track.
>
> Anyway...
iginal Message-
From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
Sent: Friday, December 27, 2019 6:16 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)
I do not know what is the problem for receiving patc
Hi, Nathan,
I remember promising to help you with the workflow document a few days
ago. I am having a little trouble following your outline. Fleshing it
out a little more would probably be helpful to keep us on track.
Anyway... I did make some first small changes today and I am addressing
-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Friday, December 27, 2019 6:01 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)
On Fri, Dec 27, 2019 at 8:26 AM David
tml/98ddb6fcf5a744f3b65f81d850cb535764f16fa207fd883c557fbf4f%40%3Cdev.nuttx.apache.org%3E
>
> David
>
>
>
> -----Original Message-----
> From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> Sent: Thursday, December 26, 2019 7:34 PM
> To: dev@nuttx.apache.org
> Subject: Re:
On Fri, Dec 27, 2019 at 8:26 AM David Sidrane
wrote:
> Nathan,
>
> I am not sure if this is a terminology issue or just being new to github.
> (I
> feel you. We have all been there!)
>
> Where do they submit the PR from?
>
>
>
g/thread.html/98ddb6fcf5a744f3b65f81d850cb535764f16fa207fd883c557fbf4f%40%3Cdev.nuttx.apache.org%3E
David
-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Thursday, December 26, 2019 7:34 PM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implication
On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) wrote:
> Yes, feature branch is another story, but I still need to say that, we
> should not just exclude normal contributors. They do not have the
> permission to push to a feature branch either...
There is no problem here. Anyone can clone the
Yes, feature branch is another story, but I still need to say that, we
should not just exclude normal contributors. They do not have the
permission to push to a feature branch either...
Yes, and that is basically what is said at that reference too. We need
to squash this notion of an
Yes, feature branch is another story, but I still need to say that, we
should not just exclude normal contributors. They do not have the
permission to push to a feature branch either...
Gregory Nutt 于2019年12月27日 周五07:52写道：
>
> > Still, not every contributors are committers, they do not have the
Still, not every contributors are committers, they do not have the
permission to create branches. How can they let others know they are
working on something? Open an issue or send an email to the mailing list
right? And usually, the contributor set is much larger than the committer
set for a
Hub+project+boards_ivs=1#tts=0
> David
>
> -Original Message-
> From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
> Sent: Thursday, December 26, 2019 7:21 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (
; PPMC
> > Rights--|--->
> >
> > No Write | Have Write access
> > Access | Do PR in upstream
> > Do PR | on Branches
> > Against|
> > Upstream|
> > On |
> > Branches |
> > in own |
>
> >
> > No Write | Have Write access
> > Access | Do PR in upstream
> > Do PR | on Branches
> > Against|
> > Upstream|
> > On |
> > Branches |
> > in own |
> > account |
> >
>
On 12/26/2019 7:49 AM, 张铎(Duo Zhang) wrote:
...
Duo should also have access to any external, third party repositories
for workflow development. He has also offered to contribute to the
NuttX workflow in the past.
From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
> Sent: Thursday, December 26, 2019 5:10 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> Hey David, could you please explain the
张铎(Duo Zhang) [mailto:palomino...@gmail.com]
Sent: Thursday, December 26, 2019 5:10 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)
Hey David, could you please explain the above questions a bit?
Since you want
t;
> -Original Message-
> From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> Sent: Wednesday, December 25, 2019 7:28 PM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
&g
On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean
wrote:
> > People on this list have indicated that they use NuttX released with
> Apache SVN.
>
> The releases are placed in a ASF SVN system to be distributed by the
> mirror system yes.
I think Greg means that users are getting the release
As long as you stick to git only features you can have everyone work
on it, so branch bases workflow would be best. You can still use
GitHub only features but just don’t make them compulsory.
WRONG!
Not also that some more advanced features or options for GItHub that
have been discussed
Hi,
> The majority of users do not use GIT at all. NuttX distributions are SCM
> neutral (all GIT information has been used).
User and contributors are different (but overlapping) groups, I believe we were
talking about contributors here. Users will be using the releases which are
available
As long as you stick to git only features you can have everyone work on it, so
branch bases workflow would be best. You can still use GitHub only features but
just don’t make them compulsory.
WRONG!
Not also that some more advanced features or options for GItHub that have been
discussed
om/en/github/managing-your-work-on-github/about-project-boards
>
>
>
> David
>
>
> -----Original Message-
> From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
> Sent: Wednesday, December 25, 2019 6:37 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release
Hi,
As long as you stick to git only features you can have everyone work on it, so
branch bases workflow would be best. You can still use GitHub only features but
just don’t make them compulsory.
Not also that some more advanced features or options for GItHub that have been
discussed here e.g
k so well together and are cross linked
> auto-magically.
>
> [1]
>
> https://help.github.com/en/github/managing-your-work-on-github/about-project-boards
>
>
>
> David
>
>
> -----Original Message-
> From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
> Sent: Wedn
: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)
On Wed, Dec 25, 2019 at 2:18 PM David Sidrane
wrote:
> Github issues and PR work so well together and are cross linked
> auto-magically.
Justin points out that some people cann
On Wed, Dec 25, 2019 at 2:18 PM David Sidrane
wrote:
> Github issues and PR work so well together and are cross linked
> auto-magically.
Justin points out that some people cannot use GitHub and Apache strives to
include everyone. I have no opposition to using GitHub and the tools and
25, 2019 6:37 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)
David Sidrane 于2019年12月25日周三 下午9:55写道：
> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao wrote:
> > Yes, I agree that we should
ent: Wednesday, December 25, 2019 6:44 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications
> on
> workflow (was RE: Single Committer)
>
>
>> If they are related / dependent on each other, then I think those
>> kinds
flow has to stop after review. (With some
exceptions) but we always attribute to the Authors
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 25, 2019 6:44 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have
-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 25, 2019 6:44 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)
> If they are related / dependent on each other, then I think th
: Wednesday, December 25, 2019 6:37 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)
David Sidrane 于2019年12月25日周三 下午9:55写道：
> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao wrote:
> > Yes,
+1
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, December 25, 2019 6:41 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)
> Why does the authors mat
-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Wednesday, December 25, 2019 6:55 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)
On Wed, Dec 25, 2019 at 9:55 PM
Hi Duo,
I am sorry I broke my own rule. I should have defined it.
BD: Benevolent dictator for life (BDFL) is a title given to a small number of
open-source software development leaders, typically project founders who retain
the final say in disputes or arguments within the community.
On
On Wed, Dec 25, 2019 at 9:55 PM David Sidrane wrote:
>
> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao wrote:
> > 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
If they are related / dependent on each other, then I think those
kinds of patchsets should be encapsulated in one branch.
That would work fine provided that the branch is not squashed to
master. That loses authorship of individual contributions.
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.
It does not matter to the project. But it matters very much to some
contributors. Especially young or newbie contributors who see this
David Sidrane 于2019年12月25日周三 下午9:55写道：
> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao wrote:
> > 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
Pardon me, what is a BD model? I do not get your point why requiring users
to send a patch or open a PR against master will hindered the community
growth? Or you say #3 and #4? These are what we want to change.
Thanks.
David Sidrane 于2019年12月25日周三 下午9:55写道：
> Hi Xiang,
>
> On 2019/12/25
Hi Xiang,
On 2019/12/25 05:36:14, Xiang Xiao wrote:
> 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
> For me on HBase, this depends on lots of things. If it is only a typo then
> I will merge it immediately. If it is a simple bug fix, I will wait a bit
> long and if some committers are familiar with this part, I will try to ask
> their opinions. And if this is a very big new feature, sometimes
On Wed, Dec 25, 2019 at 2:30 PM 张铎(Duo Zhang) wrote:
>
> 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
Hi,
> 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.
This depends on the projects, some don’t
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,
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
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
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
[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 becom
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
72 matches
Mail list logo
