Re: Testing the new repository
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
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
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 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
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 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
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
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
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
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
> >> 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 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
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
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
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
> >>> 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
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
> > 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/ a simple fix for some bug in OS, driver, or app... hotfix/ an emergency fix to some bug in a released version feature/ add a new driver, or new feature releases/ 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
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 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
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
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 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
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
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
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
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 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 > 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
+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 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 >> 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
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 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
-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 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
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 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
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" 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
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.
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". 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.
