Re: Making the "new repo" requests go faster

[Brad Bishop <bradleyb@fuzziesquirrel.com>]

On Fri, Feb 05, 2021 at 12:02:31PM -0800, Ed Tanous wrote:
>An issue I've seen in the past with adding new repositories, is there:
>1. Isn't a clear place to push code reviews for something "new".
>2. The project quality/CI/formatting rules aren't really enforced
>until after you request a repo, then push code to it.
>3. Setting up a new daemon with CI/build is non-trivial, and has sharp edges.
>4. "state of the art" build constantly changes (make -> autotools ->
>cmake -> meson, clang-format, clang-tidy, shellcheck, cppcheck,
>service file location, ect).
>
>In an effort to fix these issues and more, I'd like to propose
>creating a new repository for a "new daemon" template.  The hope would
>be that we can centralize a single set of "current state of the art"
>guidelines in such a way that they're usable more than just checking
>them into documentation.  Initially, template repo would contain:
>
>1. A meson file, that compiles a "hello world" dbus application that
>requests a name.
>2. All the relevant .clang-tidy, .clang-format, and cppcheck files
>required to ensure that CI is testing as much as we can.
>3. Unit tests
>4. Pre-integrated repo CI.
>
>The end goal of this would be that when new code is created, whomever
>was looking for a new repository could push a gerrit review to this
>"template repo" and the CI could ensure that it met the automated
>quality requirements long before any maintainer actually reviewed it.
>This would likely reduce the time it takes to propose "I want to add a
>new repo" and make a procedure for doing it a lot more concrete than
>sending an email to the mailing list.
>
>As part of this, I'd also want to deprecate and remove the .clang-tidy
>and .clang-format that are present in the docs repo, and supersede
>them with the files in the new repo, such that any changes to the CI
>infrastructure could be proposed on the template repo first.
>
>FWIW, I take no credit for the above idea, I 100% stole it from James
>Feist, who thought through the broad strokes of this a while back when
>we were talking about how to move new initiatives along faster without
>burdening maintainers.
>
>I'd love feedback.  Do others think this worth doing?

Yes!

These are all great ideas.  Thanks for tackling this.

Since I'm the only one with the right gerrit/github authority to create 
repos, I've obviously been the cause of the delay (there are others that 
can but this isn't really something they'd be comfortable doing).

For the record, making new repos from a logistics point of view is not 
hard and not any sort of burden on me.  I'm happy to do that.

I don't know if this is a good excuse or not, but I just want to say 
that in a some of the past cases making the repository took so long 
simply because there did not seem to be any clear consensus on whether 
the new repo was good or bad for OpenBMC.  When you combine that with 
the fact that I'm not really good at making unilateral decisions, many 
times the result was "analysis paralysis" on my part.  This is a big 
part of why I'm creating and excited about this: 

https://lore.kernel.org/openbmc/20210111220919.zwc727vbwc4itm7h@thinkpad.fuzziesquirrel.com/#t

-brad