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
ave implications on
workflow (was RE: Single Committer)
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 b
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
&
Duo Zhang) [mailto:palomino...@gmail.com]
> Sent: Thursday, December 26, 2019 5:49 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications
> on
> workflow (was RE: Single Committer)
>
> Then why committers have a different workf
]
> Sent: Thursday, December 26, 2019 5:49 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> Then why committers have a different workflow comparing to contributors?
> Why not also c
hoices could have implications on
workflow (was RE: Single Committer)
Then why committers have a different workflow comparing to contributors?
Why not also create branches in your own forked repo?
David Sidrane 于2019年12月26日周四 下午9:36写道：
> Hi Duo,
>
>
> Sure - I just do not which above
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
cycle choices could have implications on
workflow (was RE: Single Committer)
Doesn't do any good at social bragging sites like https://codersrank.io/
On 12/25/2019 9:47 AM, David Sidrane wrote:
> Even on a squashed merge there is traceability back to the PR and
> therefore
> ALL th
have implications on
workflow (was RE: Single Committer)
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 indiv
-
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
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 gro
+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 th
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
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 m
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
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
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
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 t
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
+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. H
--
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 checke
]
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
+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
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
>
+1
the old way of working was ok but this will put pressure on Greg again.
We should define the workflow as soon as possible and work as we are
intended to.
On Tue, Dec 24, 2019, 09:48 Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:
> This makes sense giving the circumstances. It wi
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 Cor
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
+1
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 abu
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
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 car
I definitely support this approach: keep the original workflow before
the new workflow setup.
We have enough time to achieve "THE APACHE WAY" step by step before
NuttX graduate to the top level project.
On Tue, Dec 24, 2019 at 8:51 AM Gregory Nutt wrote:
>
> Recent events have made me reconsider
+1.
I think it is reasonable to just keep the original workflow as is for now,
as we still need to make progress on the project. I do not think the ASF
will 'hate' this, you can not graduate if you keep doing things like this,
that's all, fair enough.
And on the workflow part, I suggest you start
97 matches
Mail list logo
