You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Alan Carvalho de Assis <ac...@gmail.com> on 2019/12/20 21:58:59 UTC
Testing the new repository
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", this way other will have the chance to review.
BR,
Alan
RE: Testing the new repository
Posted by David Sidrane <Da...@nscdg.com>.
-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@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 STM32G070/NUCLEO-G070RB that was added
>> to bitbucket.
>>
>> As a rules of thumb, please don't commit directly to the "master".
+1
We should ask if info can branch protected master (settings panel in GH),
but I have no idea how or if that will work the ASF cross sync.
>>
>> I created a brash called "stage" that we could use before merging in
>> to "master", this way other will have the chance to review.
>That seems like a good sense. Except aren't you creating a workflow
>definition from thin air. I suppose that is natural in a vaccum -- even
>thin air is more substantial than a vacuum -- but we really need to
>define such rules in a workflow requirements document.
In an a attempt to fill the vaccum - A skeleton [CALL for TOP Down workflow
Requirements] has been posted
Please help update and integrate what you want from the previous discussion
Re: Testing the new repository
Posted by Disruptive Solutions <di...@gmail.com>.
This looks progress!! Good job!!
Verstuurd vanaf mijn iPhone
> Op 20 dec. 2019 om 23:10 heeft Alan Carvalho de Assis <ac...@gmail.com> het volgende geschreven:
>
> On 12/20/19, Gregory Nutt <sp...@gmail.com> 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" that we could use before merging in
>>> to "master", this way other will have the chance to review.
>>
>> That seems like a good sense. Except aren't you creating a workflow
>> definition from thin air. I suppose that is natural in a vaccum -- even
>> thin air is more substantial than a vacuum -- but we really need to
>> define such rules in a workflow requirements document.
>>
>
> Hehehe, I agree!
>
> It is better to have a minimum logic sequence to follow before the
> workflow get defined. Otherwise the chaos will reign. I'm open to
> suggestions.
>
> I think now we are feeling that things are moving to Apache project.
>
> BR,
>
> Alan
Re: Testing the new repository
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
On 12/20/19, Gregory Nutt <sp...@gmail.com> 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" that we could use before merging in
>> to "master", this way other will have the chance to review.
>
> That seems like a good sense. Except aren't you creating a workflow
> definition from thin air. I suppose that is natural in a vaccum -- even
> thin air is more substantial than a vacuum -- but we really need to
> define such rules in a workflow requirements document.
>
Hehehe, I agree!
It is better to have a minimum logic sequence to follow before the
workflow get defined. Otherwise the chaos will reign. I'm open to
suggestions.
I think now we are feeling that things are moving to Apache project.
BR,
Alan
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
> 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 way other will have the chance to review.
That seems like a good sense. Except aren't you creating a workflow
definition from thin air. I suppose that is natural in a vaccum -- even
thin air is more substantial than a vacuum -- but we really need to
define such rules in a workflow requirements document.
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
> 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.
Re: Testing the new repository
Posted by Disruptive Solutions <di...@gmail.com>.
+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 <xi...@gmail.com> het volgende geschreven:
>
> 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 that PMC member is starting to create the branch in the
> offical repo as they see the needed.
> If we don't control this situation, we will have dozen(even hundred)
> of branches in the offical repo soon.
> These random named and created branches just confuse people who clone the repo.
> It's important to keep the original workflow and ensure all patches
> reviewed and committed by Greg before the automation tool is ready.
>
> Thanks
> Xiang
>
>
>> On Sat, Dec 21, 2019 at 5:59 AM Alan Carvalho de Assis
>> <ac...@gmail.com> wrote:
>>
>> 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", this way other will have the chance to review.
>>
>> BR,
>>
>> Alan
Re: Testing the new repository
Posted by "David S. Alessio" <da...@gmail.com>.
>
> 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 is key
>
> 'master_imxrt' is too master_imxrt
> `stage` is too vague
> `master-pr-imxrt_imxrt_fixes` - Says what it is: A PR against the branch master that fixes the imxrt.
>
> master has always been master in the context of nuttx and as well on gitub as the default branch.
we should consider adopting a naming convention that classifies the category of the PR. BitBucket’s scheme works very well and helps keep live (yet to be reviewed/merged) branches organized:
bugfix/<descriptive-name-of-bug>
a simple fix for some bug in OS, driver, or app...
hotfix/<descriptive-name-of-bug>
an emergency fix to some bug in a released version
feature/<descriptive-name-of-new-feature>
add a new driver, or new feature
releases/<number-or-descriptive-name>
if a release need to be patched, the hotfix first applies here, then can be cherry-picked and merged to master.
Regards,
-david
Re: Testing the new repository
Posted by Justin Mclean <ju...@classsoftware.com>.
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 suggestions?
The mentors have offered suggestions (mostly on the private list). One was to move discussions off that list and here so others can be involved. Some f that is what you are seeing.
> And the license switch could bring uncertainty also for some?
Why do you think that? I’m curious as both are permissive compatible licenses.
> Thats where Apache could cone to the rescue?
Apache does offer CI, this project has just not set it up yet. See https://ci.apache.org/buildbot.html https://builds.apache.org and https://ci2.apache.org/. You can also use CI platforms other than Jenkins.
Thanks,
Justin
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
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 hope they/we can all learn to work together better.
If not, NuttX will enter into its dark ages, lose its following, and
become irrelevant like so many RTOSs before it.
We can only wait and see. Buy some popcorn and try to get a seat in the
front row. It will be interesting.
Greg
On 12/21/2019 8:14 PM, Disruptive Solutions wrote:
> 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 uncertainty?
>
> I thought Apache would bring in their workflow and automated tooling and experience with these projects? But now it seems that the Nuttx/Bitbucket workflow was not that bad..... it worked from 2007... so how bad was it really? Oké only Greg as master committer was a SPOF... but could be fixed also right? Maybe Apache can chip in to come with suggestions?
>
> I personally think that there are people who still believe in the greatness of Nuttx but are waiting for a good progress and more solid and stable choices? And maybe people want to help out but are not in a position to do so? And the license switch could bring uncertainty also for some?
>
> I can only say that change is always good, but it gives insight and insight gives change!! So I hope you all find a solution to maybe a minor problem.... Nuttx was already a succes, just needs some automation and it has the same problems in CI/CD like every large project in C in teams at other big firms..?? Thats where Apache could cone to the rescue? As a big software deployer?
>
> Maybe this articles gives one some ideas:
>
> https://proandroiddev.com/how-to-set-up-an-efficient-development-workflow-with-git-and-ci-cd-5e8916f6bece
>
> Heads up and keep believing!
>
> Maybe I should not share my thought, but like most of us I do not care what other people think :-) I am just concerned..
>
> A spectator....
> Ben
>
>
> Verstuurd vanaf mijn iPhone
>
>> Op 22 dec. 2019 om 02:34 heeft Gregory Nutt <sp...@gmail.com> het volgende geschreven:
>>
>>
>>>> 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 liberated. So I don't really want to do that at all anymore. It is the PPMC's responsibility to manage the workflow, not mine. It is better that way.
>> Related thoughts:
>>
>> I did tell the IPMC before the project was voted in there would be a knife-edge transition: The day that the Apache repositories are created would be the day that I stop updating Bitbucket and turn over full responsibility of the changes to the PPMC.
>>
>> Despite some confusion, I have met that commitment. There have been no further changes to Bitbucket and the PPMC now has full responsibility for the disposition of changes.
>>
>> 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 future.
>>
>> 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 coordination.
>>
>>
Re: Testing the new repository
Posted by Disruptive Solutions <di...@gmail.com>.
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 uncertainty?
I thought Apache would bring in their workflow and automated tooling and experience with these projects? But now it seems that the Nuttx/Bitbucket workflow was not that bad..... it worked from 2007... so how bad was it really? Oké only Greg as master committer was a SPOF... but could be fixed also right? Maybe Apache can chip in to come with suggestions?
I personally think that there are people who still believe in the greatness of Nuttx but are waiting for a good progress and more solid and stable choices? And maybe people want to help out but are not in a position to do so? And the license switch could bring uncertainty also for some?
I can only say that change is always good, but it gives insight and insight gives change!! So I hope you all find a solution to maybe a minor problem.... Nuttx was already a succes, just needs some automation and it has the same problems in CI/CD like every large project in C in teams at other big firms..?? Thats where Apache could cone to the rescue? As a big software deployer?
Maybe this articles gives one some ideas:
https://proandroiddev.com/how-to-set-up-an-efficient-development-workflow-with-git-and-ci-cd-5e8916f6bece
Heads up and keep believing!
Maybe I should not share my thought, but like most of us I do not care what other people think :-) I am just concerned..
A spectator....
Ben
Verstuurd vanaf mijn iPhone
> Op 22 dec. 2019 om 02:34 heeft Gregory Nutt <sp...@gmail.com> het volgende geschreven:
>
>
>>> 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 liberated. So I don't really want to do that at all anymore. It is the PPMC's responsibility to manage the workflow, not mine. It is better that way.
>
> Related thoughts:
>
> I did tell the IPMC before the project was voted in there would be a knife-edge transition: The day that the Apache repositories are created would be the day that I stop updating Bitbucket and turn over full responsibility of the changes to the PPMC.
>
> Despite some confusion, I have met that commitment. There have been no further changes to Bitbucket and the PPMC now has full responsibility for the disposition of changes.
>
> 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 future.
>
> 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 coordination.
>
>
Re: Testing the new repository
Posted by Justin Mclean <ju...@classsoftware.com>.
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 coordination.
There’s probably a few reasons:
- The move to Apache. People may have patches ready for the old repo but don’t know how to apply it here.
Workflow not clearly defined yet
- Not ovary one was move over to these mailing lists
- The holiday season (how does it compare to last year same time?)
One other possible reason is that the project has forked and it's been developed elsewhere, but I guess that news would be a bit more public, so that seems unlikely.
Thanks,
Justin
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
> 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 future.
>
> 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 coordination.
Or, more likely, it is just the Christmas season?
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
>> 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 liberated. So I don't
> really want to do that at all anymore. It is the PPMC's
> responsibility to manage the workflow, not mine. It is better that way.
Related thoughts:
I did tell the IPMC before the project was voted in there would be a
knife-edge transition: The day that the Apache repositories are created
would be the day that I stop updating Bitbucket and turn over full
responsibility of the changes to the PPMC.
Despite some confusion, I have met that commitment. There have been no
further changes to Bitbucket and the PPMC now has full responsibility
for the disposition of changes.
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 future.
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 coordination.
Re: Testing the new repository
Posted by Justin Mclean <ju...@classsoftware.com>.
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 projects use social convention rather than technology to stop people from doing the wrong thing, having a commit bit is a responsibility and it’s expected you’ll use it wisely (or not at all).
Thanks,
Justin
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
>>>> 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 the syncing part.
>> Yes, we did agree to that, at least everyone who expressed an opinion
>> agreed (there was no vote).
> 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 liberated. So I don't
really want to do that at all anymore. It is the PPMC's responsibility
to manage the workflow, not mine. It is better that way.
Greg
Re: Testing the new repository
Posted by Abdelatif Guettouche <ab...@gmail.com>.
> >> 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 the syncing part.
> Yes, we did agree to that, at least everyone who expressed an opinion
> agreed (there was no vote).
Can we do that for the PR that David created? (I mean applying it on
bitbucket and I bring it to github)
On Sat, Dec 21, 2019 at 8:38 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> 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 PM, Gregory Nutt wrote:
> >
> >>>> 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 nitty-gritty. And if we stratify the details, the resultant docs should be welcoming to all.
> >>>
> >>> I’d like to give it a go. Anyone up for this?
> >>>
> >> I don't believe it is a difficult job. I think it is like one or two
> >> hours of work for a straw man. And unless there is fundamental
> >> tool/implementation problem, I don't thing that you need to delve
> >> deeply into git or github. I think the workflow is really pretty
> >> trivial.
> >>
> >> 1. Receive patches or PRs and put on a branch
> >> 2. Make sure that they conform to the coding standard
> >> 3. [FUTURE] make sure that they conform to Apache licensing
> >> requirements.
> >> 4. Make sure that they don't break the build (trickier than it sounds)
> >> 5. [FUTURE] perform hardware- or simulator-in-loop testing to check
> >> for regressions
> >> 6. Final review for architectural correctness and conformance to
> >> standard. Make sure that the change follow same pattern as other
> >> instances (if applicable)
> >> 7. Merge the change in master
> >>
> >> Oh, damn! I just did the job. :-) From my point of view, the is
> >> about 80% of the workflow. The rest is all the caveats and what to
> >> do if a step fails which will require more words.
> >>
> > It would be best to have a place where we can collaborate on a
> > document. Something like Google Drive. Apache, however, is very
> > particular about everything happening in the open. When asked,
> > Justin, one of our mentors, recommended that we put the collaborative
> > document in the Nuttx Confluence. As I mentioned to Brennan earlier,
> > it would be good to have a page outside of the User Wiki to hold
> > project documents... a Project Wiki. But that hasn't stirred up any
> > response.
> >
> > I think we have all become a little jaded :-(
> >
> > Having a fresh point of view would be great!
> >
> > Greg
> >
> >
>
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
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 PM, Gregory Nutt wrote:
>
>>>> 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 nitty-gritty. And if we stratify the details, the resultant docs should be welcoming to all.
>>>
>>> I’d like to give it a go. Anyone up for this?
>>>
>> I don't believe it is a difficult job. I think it is like one or two
>> hours of work for a straw man. And unless there is fundamental
>> tool/implementation problem, I don't thing that you need to delve
>> deeply into git or github. I think the workflow is really pretty
>> trivial.
>>
>> 1. Receive patches or PRs and put on a branch
>> 2. Make sure that they conform to the coding standard
>> 3. [FUTURE] make sure that they conform to Apache licensing
>> requirements.
>> 4. Make sure that they don't break the build (trickier than it sounds)
>> 5. [FUTURE] perform hardware- or simulator-in-loop testing to check
>> for regressions
>> 6. Final review for architectural correctness and conformance to
>> standard. Make sure that the change follow same pattern as other
>> instances (if applicable)
>> 7. Merge the change in master
>>
>> Oh, damn! I just did the job. :-) From my point of view, the is
>> about 80% of the workflow. The rest is all the caveats and what to
>> do if a step fails which will require more words.
>>
> It would be best to have a place where we can collaborate on a
> document. Something like Google Drive. Apache, however, is very
> particular about everything happening in the open. When asked,
> Justin, one of our mentors, recommended that we put the collaborative
> document in the Nuttx Confluence. As I mentioned to Brennan earlier,
> it would be good to have a page outside of the User Wiki to hold
> project documents... a Project Wiki. But that hasn't stirred up any
> response.
>
> I think we have all become a little jaded :-(
>
> Having a fresh point of view would be great!
>
> Greg
>
>
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
>>> 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 nitty-gritty. And if we stratify the details, the resultant docs should be welcoming to all.
>>
>> I’d like to give it a go. Anyone up for this?
>>
> I don't believe it is a difficult job. I think it is like one or two
> hours of work for a straw man. And unless there is fundamental
> tool/implementation problem, I don't thing that you need to delve
> deeply into git or github. I think the workflow is really pretty trivial.
>
> 1. Receive patches or PRs and put on a branch
> 2. Make sure that they conform to the coding standard
> 3. [FUTURE] make sure that they conform to Apache licensing requirements.
> 4. Make sure that they don't break the build (trickier than it sounds)
> 5. [FUTURE] perform hardware- or simulator-in-loop testing to check
> for regressions
> 6. Final review for architectural correctness and conformance to
> standard. Make sure that the change follow same pattern as other
> instances (if applicable)
> 7. Merge the change in master
>
> Oh, damn! I just did the job. :-) From my point of view, the is about
> 80% of the workflow. The rest is all the caveats and what to do if a
> step fails which will require more words.
>
It would be best to have a place where we can collaborate on a
document. Something like Google Drive. Apache, however, is very
particular about everything happening in the open. When asked, Justin,
one of our mentors, recommended that we put the collaborative document
in the Nuttx Confluence. As I mentioned to Brennan earlier, it would be
good to have a page outside of the User Wiki to hold project
documents... a Project Wiki. But that hasn't stirred up any response.
I think we have all become a little jaded :-(
Having a fresh point of view would be great!
Greg
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
>> 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 nitty-gritty. And if we stratify the details, the resultant docs should be welcoming to all.
>
> I’d like to give it a go. Anyone up for this?
>
I don't believe it is a difficult job. I think it is like one or two
hours of work for a straw man. And unless there is fundamental
tool/implementation problem, I don't thing that you need to delve deeply
into git or github. I think the workflow is really pretty trivial.
1. Receive patches or PRs and put on a branch
2. Make sure that they conform to the coding standard
3. [FUTURE] make sure that they conform to Apache licensing requirements.
4. Make sure that they don't break the build (trickier than it sounds)
5. [FUTURE] perform hardware- or simulator-in-loop testing to check for
regressions
6. Final review for architectural correctness and conformance to
standard. Make sure that the change follow same pattern as other
instances (if applicable)
7. Merge the change in master
Oh, damn! I just did the job. :-) From my point of view, the is about
80% of the workflow. The rest is all the caveats and what to do if a
step fails which will require more words.
Re: Testing the new repository
Posted by "David S. Alessio" <da...@gmail.com>.
>
>>> 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, today, are inextricably tied to the tools used to implement them; and the one common tool is git (I don’t believe anyone has or would suggest any alternative).
>>
>> There seem to be [quite] a few people here with devops experience, as users, and a few as disciplined admins. I think it’s incumbent upon those of us with that expertise and experience to come together and define a candidate workflow and present it to the larger team.
>
> But that also excludes all people from the conversation that don't speak the language. At some point, the requirements must be expressed in a way that communicates what it does to every person of every background.
Agreed, that document then becomes the “on ramp” and guide for those still climbing the learning curve.
>
> This kind of tool-based thinking must also be constantly be monitored so that it does not degenerate in a what-is-best-for-the-tool conversation instead of a what-is best-for-end-user conversation. The latter critical. Often people will sacrifice usability to make tool integration easier. We cannot let that happen.
Again, I could not agree with you more. This is why discipline is important.
>
> But I agree with you in part. The top level specification is like a boat on the surface of the water and it does help to have a glass bottom to see what is going on beneath.
I like the analogy.
> 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 nitty-gritty. And if we stratify the details, the resultant docs should be welcoming to all.
I’d like to give it a go. Anyone up for this?
>
> Greg
>
>
>
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
>> 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, today, are inextricably tied to the tools used to implement them; and the one common tool is git (I don’t believe anyone has or would suggest any alternative).
>
> There seem to be [quite] a few people here with devops experience, as users, and a few as disciplined admins. I think it’s incumbent upon those of us with that expertise and experience to come together and define a candidate workflow and present it to the larger team.
But that also excludes all people from the conversation that don't speak
the language. At some point, the requirements must be expressed in a
way that communicates what it does to every person of every background.
This kind of tool-based thinking must also be constantly be monitored so
that it does not degenerate in a what-is-best-for-the-tool conversation
instead of a what-is best-for-end-user conversation. The latter
critical. Often people will sacrifice usability to make tool
integration easier. We cannot let that happen.
But I agree with you in part. The top level specification is like a
boat on the surface of the water and it does help to have a glass bottom
to see what is going on beneath. Those people with devops should
coordinate in another thread and make proposals for top-level functional
to the broader audience.
Greg
Re: Testing the new repository
Posted by "David S. Alessio" <da...@gmail.com>.
>
> 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, today, are inextricably tied to the tools used to implement them; and the one common tool is git (I don’t believe anyone has or would suggest any alternative).
There seem to be [quite] a few people here with devops experience, as users, and a few as disciplined admins. I think it’s incumbent upon those of us with that expertise and experience to come together and define a candidate workflow and present it to the larger team.
Regards,
-david
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
On 12/21/2019 8:38 AM, Abdelatif Guettouche wrote:
>> 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 the syncing part.
Yes, we did agree to that, at least everyone who expressed an opinion
agreed (there was no vote). Nothing else was ever proposed until the
last minute. I cannot work on the AFS repositories because there is
abuse from peoples ability to write directly into the repository with no
oversight. That is totally unacceptable to me. So I will work on
Bitbucket or nothing.
> Couple people suggested to switch all the work to github and make
> bitbucket a mirror.
> But that didn't get enough attention since we are still trying to
> define the workflow.
There is no workflow definition. DavidS started a thread, but so far it
has only general principles, no work flow.
Greg
Re: Testing the new repository
Posted by Abdelatif Guettouche <ab...@gmail.com>.
> 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 the syncing part.
Couple people suggested to switch all the work to github and make
bitbucket a mirror.
But that didn't get enough attention since we are still trying to
define the workflow.
On Sat, Dec 21, 2019 at 1:24 PM Gregory Nutt <sp...@gmail.com> wrote:
>
>
> > 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.
>
> Because of the recent experiences on the Apache repo, I do not want that
> job. I will let someone else do it.
>
>
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
> 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.
Because of the recent experiences on the Apache repo, I do not want that
job. I will let someone else do it.
Re: Testing the new repository
Posted by Xiang Xiao <xi...@gmail.com>.
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 PM Gregory Nutt <sp...@gmail.com> wrote:
>
>
> > 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 weeks?
>
> I am retiring from my job of reviewing and incorporating patches. That
> is fully in the hands of the PPMC now. I do not want to do that any
> more, especially not in the current circumstances.
>
> 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.
>
> Trying to manage a repository where people can make any kind of
> modification that they want is impossible and I will not take that job
> under those circumstances.
>
> If you want me to do this, then everything must come through the
> bitbucket repos. Otherwise, I will let the PPMC deal with the lack of
> discipline as it sees fit.
>
>
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
> 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 weeks?
I am retiring from my job of reviewing and incorporating patches. That
is fully in the hands of the PPMC now. I do not want to do that any
more, especially not in the current circumstances.
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.
Trying to manage a repository where people can make any kind of
modification that they want is impossible and I will not take that job
under those circumstances.
If you want me to do this, then everything must come through the
bitbucket repos. Otherwise, I will let the PPMC deal with the lack of
discipline as it sees fit.
Re: Testing the new repository
Posted by Xiang Xiao <xi...@gmail.com>.
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 weeks?
On Sat, Dec 21, 2019 at 8:55 PM Gregory Nutt <sp...@gmail.com> wrote:
>
>
> > 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.
> You might as well just merge it to master now. I am out of the loop on
> all further changes.
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
> 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.
You might as well just merge it to master now. I am out of the loop on
all further changes.
Re: Testing the new repository
Posted by David Sidrane <da...@apache.org>.
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 (choose from the green drop down))
However the changes to the IMXrt are critical so please insure the patch get applied/
more below
On 2019/12/21 11:30:27, Xiang Xiao <xi...@gmail.com> wrote:
> 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 that PMC member is starting to create the branch in the
> offical repo as they see the needed.
> If we don't control this situation, we will have dozen(even hundred)
> of branches in the offical repo soon.
That is a good thing it means a project is health and being worked on but you right that the chaos has to be controlled.
PR branches are (hopefully) very short lived as they are deleted when committed and discernible as a PR on github.
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 is key
'master_imxrt' is too master_imxrt
`stage` is too vague
`master-pr-imxrt_imxrt_fixes` - Says what it is: A PR against the branch master that fixes the imxrt.
master has always been master in the context of nuttx and as well on gitub as the default branch.
> It's important to keep the original workflow and ensure all patches
> reviewed and committed by Greg before the automation tool is ready.
>
> Thanks
> Xiang
>
>
> On Sat, Dec 21, 2019 at 5:59 AM Alan Carvalho de Assis
> <ac...@gmail.com> wrote:
> >
> > 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", this way other will have the chance to review.
> >
> > BR,
> >
> > Alan
>
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
>
>> 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 already fallen apart. I think will make no further commits
> at all. I will leave handling of all changes to the PPMC
Fortunately, all submissions of changes have come to a screeching halt
this week. I think there have been around 5 patches/PRs this entire
week. To me, this is a clear indication that the community has lost
confidence in the project.
We will have to re-earn their trust by making clear rules and following
them.
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
> 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 already fallen apart. I think will make no further commits at
all. I will leave handling of all changes to the PPMC
> I am seeing that PMC member is starting to create the branch in the
> offical repo as they see the needed.
I also thought that was an abuse of privilege. I don't know how to
manage it since everyone is an equal and there is no workflow in place.
PPMC members can choose to ignore the workflow if they want. There is
nothing to prevent them from doing that.
> If we don't control this situation, we will have dozen(even hundred)
> of branches in the offical repo soon.
There have been only a couple of surprises, but PPMC members are all not
just making seat of the pants decisions. It is truly on the verge of
being out of control.
> These random named and created branches just confuse people who clone the repo.
> It's important to keep the original workflow and ensure all patches
> reviewed and committed by Greg before the automation tool is ready.
I will stop all commits until this can be worked out by the PPMC.
Greg
Re: Testing the new repository
Posted by Xiang Xiao <xi...@gmail.com>.
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 that PMC member is starting to create the branch in the
offical repo as they see the needed.
If we don't control this situation, we will have dozen(even hundred)
of branches in the offical repo soon.
These random named and created branches just confuse people who clone the repo.
It's important to keep the original workflow and ensure all patches
reviewed and committed by Greg before the automation tool is ready.
Thanks
Xiang
On Sat, Dec 21, 2019 at 5:59 AM Alan Carvalho de Assis
<ac...@gmail.com> wrote:
>
> 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", this way other will have the chance to review.
>
> BR,
>
> Alan
Re: Testing the new repository
Posted by Gregory Nutt <sp...@gmail.com>.
> 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 same). The bitbucket repositories are not set up as
mirrors, but I can force them to mirror the apache repositories in this way.