Making the "new repo" requests go faster

[Ed Tanous]

On Fri, Feb 5, 2021 at 12:58 PM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
> 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:

In a lot of these cases the community consensus is really hard because
there's no code to look at, just a short description of what could
theoretically go in that repo.  I think a lot of that becomes easier
if we invert the model, as we can talk in concrete technical terms,
coordinate on gerrit, and have the recipes up and building so others
can determine their utility long before the repo is created.

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

I think this will help a ton as well.

> -brad