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 locally
+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 br
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 https://github.com/apache/incubator-nuttx-website/branch
or stale
work just make the newbie confusion.
>
> 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 implicat
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.com]
> Sent: Friday, December 27, 2019 6:27 AM
> To: dev@nuttx.apache.org
> Subject: Re: S
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 / contr
/branches
>
> 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:sp
s 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 release life cycle choices could have implications on
workflow (was RE: Sing
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... I
O
-Original 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 rece
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
David
-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
.apache.org/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
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?
>
>
> https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-requ
lists.apache.org/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 h
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 rep
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 uninhibi
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 pro
use+GitHub+project+boards&gs_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
&
<committers < PPMC
> > Rights--|--->
> >
> > No Write | Have Write access
> > Access | Do PR in upstream
> > Do PR | on Branches
> > Against |
> > Upstream|
> > On |
> >
-->
> >
> > No Write | Have Write access
> > Access | Do PR in upstream
> > Do PR | on Branches
> > Against|
> > Upstream|
> > On |
> > Branches |
> > in own |
> > account |
>
gt; account |
>
>
> David
>
> -Original Message-
> 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
> workf
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
; David
>
> -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)
.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)
On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean
wrote:
> > People on this list have indicated that they use Nut
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 tarball
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 he
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 he
//help.github.com/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: So
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
sues and PR work 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]
: 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
conven
sday, 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, I agree
gt; 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 those
>> k
work 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
-
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 matter. Th
-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 2019/
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 a
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 workfl
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 05:36:1
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 it
> 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 pe
What I mean is that, nobody wants its patch to be reverted right? So you
will find a proper way to archive this. There is no straight forward rule
on how much time to wait.
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
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 workflow,
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 have
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 summar
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 contributors.
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 d
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
b
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"
sta
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 user
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 co
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 fix
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 mo
>
>
>
>
> 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 G
[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
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 woul
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
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)
st
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 mast
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/cha
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/changi
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 branc
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 goa
>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 goa
80 matches
Mail list logo