All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bills, Jason M" <jason.m.bills@linux.intel.com>
To: openbmc@lists.ozlabs.org
Subject: Re: Making the "new repo" requests go faster
Date: Mon, 8 Feb 2021 09:27:41 -0800	[thread overview]
Message-ID: <c3485284-2ead-ec47-e277-da1694fb6127@linux.intel.com> (raw)
In-Reply-To: <CACWQX80G75i+s8Vcro64uEyvcZn1Dc60y-coS6GqrvkJo59Kqg@mail.gmail.com>



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
> 

  parent reply	other threads:[~2021-02-08 17:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-05 20:02 Making the "new repo" requests go faster Ed Tanous
2021-02-05 20:58 ` Brad Bishop
2021-02-08 18:08   ` Ed Tanous
2021-02-08 17:27 ` Bills, Jason M [this message]
2021-02-08 18:09   ` Ed Tanous
2021-03-05 19:02 ` Ed Tanous
2021-03-09 13:57   ` Brad Bishop
2021-03-09 15:03     ` Ed Tanous
2021-03-09 17:32       ` Milton Miller II
2021-03-09 17:57         ` Ed Tanous
2021-03-09 18:24           ` Milton Miller II
2021-03-09 18:50             ` Ed Tanous

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3485284-2ead-ec47-e277-da1694fb6127@linux.intel.com \
    --to=jason.m.bills@linux.intel.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.