Making the "new repo" requests go faster
Bills, Jason M
jason.m.bills at linux.intel.com
Tue Feb 9 04:27:41 AEDT 2021
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.
>
> 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