> >> 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 <spudan...@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 > > > > >
