On Tue, Dec 31, 2019 at 3:01 PM Gregory Nutt <spudan...@gmail.com> wrote: > > That was actually necessary. We don't want to build a huge backlog. > > I still have some fears about what is going to happen after the > holidays. My experience is that things pick up slowly after the New > Year. So we have another week or so until go back to their normal rates. > > Even then, I don't know what is going to happen. Will people hold back > changes because of the instability of the project? Or will things > continue as before? I was disposing of around 50 changes per week for > much of last year. To get that done with a consistent level of quality, > we will need clear workflow requirements and some automated help. > > I spent about a half a day every day dealing with changes. > > If things go back to a rate like that, we cannot allow a backlog to > build up.. not even for one week. So I suspect we will have to take > some exceptional measures like this until we are fully ready.
The goal is to (eventually) remove this burden from Greg entirely and have our (small but growing) army of committers reviewing and merging changes. I think it would benefit us as a community to start moving toward that goal sooner rather than later. I know that the workflow document is nowhere near ready. But I also think that the issues were discussed and debated quite a lot and it seems that some unspoken consensus has been reached on the direction and style of the workflow, even as many details remain to be hashed out. Would it make sense, then, to begin a transition period now? That is, start a gradual move from the current state where Greg is reviewing and merging all changes, toward the direction where other committers are reviewing/merging changes. Perhaps, for the next couple of weeks, Greg could continue reviewing and merging to the more finicky areas like the build system, while other committers start getting their feet wet by reviewing and merging changes to areas less likely to bring breakage? I think Greg should be mentoring us in the art of handling contributions, instead of doing all the drudge work himself. Now this, of course, requires that everyone respect the idea that being a committer doesn't give anyone license to bring in changes willy-nilly. Changes are only merged after an appropriate level of review. Until we have a workflow document that defines exactly what that means, we will have to use our best judgment. If you're fixing typos or bringing code into compliance with nxstyle without introducing functional changes, that doesn't require much review at all. If you're making functional changes, it's best to have some more eyes on the code. Thoughts? Nathan P.S., And meanwhile, we have to get that workflow document finished (and will appreciate help from the community). It is at: https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow+--+Brennan+Ashton
