Hi,
> I thought Apache would bring in their workflow and automated tooling and
> experience with these projects?
The workflow and tooling is up to this project to determine. Apache has
resources that the project can use if it needs to do so.
> Maybe Apache can chip in to come with
Hi,
> It is bad because I interpret this to mean that people have lost confidence
> in the project and are just no longer submitting changes. There could be
> other reasons, but if it is due to lack of confidence that would be an
> indication that the project is being damaged by the lack of
I understand you concerns. I have them too. Things do not look good
now. The brand has been damaged. And things will probably get worse
before they get better. How optimistic am I in that? Not very. But
there are some very talented people who volunteered to work on this
project and I
Thats what I stated from day 1. Maybe its an idea to come up with a plan /
roadmap so people can see whats going on and what has to be done and which
issues are there... lead people . now its grey and shady over A) expertise
B) progress their in the dark now? These mails are giving back
There is essential no change activity in the project. Normally there
are might be 50 changes per week, but I think that there were only 6
last week. That is good and bad. It is good because I don't see any
reason for the PPMC to fear it is going to overwhelmed by changes in
the near
Can we do that for the PR that David created? (I mean applying it on
bitbucket and I bring it to github)
It would takes some agreement to do that. But I don't want to do that
either anymore. The more I think about not having to apply patches
everyday, the better I feel about it. I feel
Hi,
BTW all committers have permission to make changes to the repo, code is usually
checked in via a RTC (review then commit - like you are doing) or CTR (commit
then review) process. Most Apache projects use CTR, but some do have RTC and
rules around who needs to review them. A lot of
When I agreed to mange the commits through the transition period, that
was conditioned on continuint to use the bitbucket repository that only
I have access to, and then syncing the Apache repositories to the
bitbucket repository. That would work.
Didn't we agree on that?
I said I would do
> >> When I agreed to mange the commits through the transition period, that
> >> was conditioned on continuint to use the bitbucket repository that only
> >> I have access to, and then syncing the Apache repositories to the
> >> bitbucket repository. That would work.
> > Didn't we agree on that?
This discussion is really on the wrong thread. It should by on the
*[CALL for TOP Down workflow Requirements]* thread. I have forward
every relevant email and document that I can find to the thread. This
conversation belongs on that thread in the proper context as well.
On 12/21/2019 2:30
Those people with devops should coordinate in another thread and make
proposals for top-level functional to the broader audience.
We have enough smart and disciplined people here, I think we can do this.
We should be able to spec from the top-level (no tool speak) process down the
the
Those people with devops should coordinate in another thread and make
proposals for top-level functional to the broader audience.
We have enough smart and disciplined people here, I think we can do this.
We should be able to spec from the top-level (no tool speak) process down the
the
>
>>> There is no workflow definition. DavidS started a thread, but so far it
>>> has only general principles, no work flow.
>>>
>> I for one struggle to “define a workflow” without using the vernacular of
>> the underlying tool (git + githug/gitlab/bitbucket). Best practices SW
>>
There is no workflow definition. DavidS started a thread, but so far it has
only general principles, no work flow.
I for one struggle to “define a workflow” without using the vernacular of the
underlying tool (git + githug/gitlab/bitbucket). Best practices SW development
workflows,
>
> If we adopt the naming conventions of using pr in the branch name then the
> fact it is a PR is self referential in nay context command line/web/tablet
>
>> These random named and created branches just confuse people who clone the
>> repo.
>
> I agree with is in part, naming as in the OS
In the transition phase, only you(Greg) can merge PR or create branch,
other PPMC member shouldn't touch the official repo.
So I think there isn't difference between bitbucket and apache? we
just change the repo location, no more change until the new workflow
setup.
On Sat, Dec 21, 2019 at 9:15
But to avoid we lose the confidence and contribution in the transition
phase, it's better that Greg has the special right to be the only
person who review and commit the code until the community agree and
setup the new workflow.
I suppose that the special period should be short and around
But to avoid we lose the confidence and contribution in the transition
phase, it's better that Greg has the special right to be the only
person who review and commit the code until the community agree and
setup the new workflow.
I suppose that the special period should be short and around several
And the patch is the same format and put on this mail address just like when we
were in the Google Group?
I would suggest holding off all changes and PRs until we get a proper
workflow in place. No one will act on them now.
I would suggest that we still follow the original process before the
new workflow is ready which mean that:
1.We post the patch to dev@nuttx.apache.org or
2.Send the pull request to https://github.com/apache/incubator-nuttx
3.Only Greg can commit the patch to apache/github repo
That has
I would suggest that we still follow the original process before the
new workflow is ready which mean that:
1.We post the patch to dev@nuttx.apache.org or
2.Send the pull request to https://github.com/apache/incubator-nuttx
3.Only Greg can commit the patch to apache/github repo
That has
Opps That would be me. I am sorry I just saw this when I was sending the PR and
the URL of the patch to the list.
I am happy to delete the branch and the PR if you like or we can use it to
explore our new environment
just let me know. (Or any PPMC can deleted it or push the merge button
+1
And the patch is the same format and put on this mail address just like when we
were in the Google Group?
Verstuurd vanaf mijn iPhone
> Op 21 dec. 2019 om 12:30 heeft Xiang Xiao het
> volgende geschreven:
>
> Hi all,
> I would suggest that we still follow the original process before
Hi all,
I would suggest that we still follow the original process before the
new workflow is ready which mean that:
1.We post the patch to dev@nuttx.apache.org or
2.Send the pull request to https://github.com/apache/incubator-nuttx
3.Only Greg can commit the patch to apache/github repo
I am seeing
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Friday, December 20, 2019 2:02 PM
To: dev@nuttx.apache.org
Subject: Re: Testing the new repository
>> We you can see the new repository is working fine.
>>
>> I submitted the i2C driver for STM32
This looks progress!! Good job!!
Verstuurd vanaf mijn iPhone
> Op 20 dec. 2019 om 23:10 heeft Alan Carvalho de Assis het
> volgende geschreven:
>
> On 12/20/19, Gregory Nutt wrote:
>>
>>> We you can see the new repository is working fine.
>>>
>>> I submitted the i2C driver for
On 12/20/19, Gregory Nutt wrote:
>
>> We you can see the new repository is working fine.
>>
>> I submitted the i2C driver for STM32G070/NUCLEO-G070RB that was added
>> to bitbucket.
>>
>> As a rules of thumb, please don't commit directly to the "master".
>>
>> I created a brash called "stage"
We you can see the new repository is working fine.
I submitted the i2C driver for STM32G070/NUCLEO-G070RB that was added
to bitbucket.
Tomorrow I will do a get fetch from apache and force bitbucket to
exactly match the apache repository (after verifying that the recent
histories are the
We you can see the new repository is working fine.
I submitted the i2C driver for STM32G070/NUCLEO-G070RB that was added
to bitbucket.
As a rules of thumb, please don't commit directly to the "master".
I created a brash called "stage" that we could use before merging in
to "master", this
Hi Guys,
We you can see the new repository is working fine.
I submitted the i2C driver for STM32G070/NUCLEO-G070RB that was added
to bitbucket.
As a rules of thumb, please don't commit directly to the "master".
I created a brash called "stage" that we could use before merging in
to "master",
30 matches
Mail list logo
