On Thu, Feb 6, 2020 at 2:40 AM Kieren MacMillan < [email protected]> wrote:
> > I suspect that you want a "less extremely granular" list > > No. I want what I asked for: a hyper-granular list like > > Patch-Related Jobs: > Patch Coding > Patch Mentoring > Patch Optimization > Patch Documentation > Patch Formatting > Patch Submission > Patch Shepherding > Patch Testing > Patch Review > Patch Approval > Patch Pushing > Patch Confirmation > > etc., in which, for example, Patch Testing and Patch Review are two > different jobs. Also note that "Patch-Related Jobs" might represent only > 1/5th of the total number of jobs in the ’Pond. > I think this is going at it from the wrong direction. The above tasks are what automation is for. For example, with clang-format, you can have a process that would automatically check if a patch is correctly formatted. The whole discussion around process/tooling is to make these jobs disappear. Graham is exactly right: we need more automation, so we can spend our time where it matters. The thing that is hard, is gaining understanding of how the code base works, and then applying that to teach others or to review potential submissions. > 1) summarize the jobs that are described in the CG > > 2) check if those descriptions are still accurate > > I’m happy to start there. I just wanted to make sure my *invention* of the > wheel wasn’t *re-*. :) > > > I suspect that "automation tools" would be the most impactful > improvements. > > Of what job(s)? If we don’t know all the steps, how they combine, how many > people can/do execute them, and what the precise toolchain options are (or > could be), talk of automating them seems premature to me. > with regard to the patch process, there is only one step that can't be automated away, and that is visual inspection of the regtest results, but this only applies if there are any, and if they were generated automatically, the reviewer and submitter could do it for themselves. -- Han-Wen Nienhuys - [email protected] - http://www.xs4all.nl/~hanwen
