Making the "new repo" requests go faster

Ed Tanous ed at tanous.net
Tue Feb 9 05:09:53 AEDT 2021


On Mon, Feb 8, 2021 at 9:29 AM Bills, Jason M
<jason.m.bills at linux.intel.com> wrote:
>
>
>
> On 2/5/2021 12:02 PM, 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.
>
> +1 on this.  This would be very helpful for knowing how to set things up
> with the latest set of tools.  I know in a crunch, I would tend to leave
> some of these things out because I don't know how to get started on them.
>
> In the future, it would also be nice to expand on the basics with some
> common enhancements such as build options in meson.

Good idea.

>
> >
> > 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?
> >
> > -Ed
> >


More information about the openbmc mailing list