Re: [libvirt PATCH] github: enable lockdown of issues and merge requests

On Fri, 2020-04-03 at 19:35 +0200, Ján Tomko wrote: > On a Friday in 2020, Andrea Bolognani wrote: > > Everything else looks good, but there's the obvious caveat that we > > can't merge the commit as-is until we have actually moved to GitLab. > > > > Since that could take a while, and locking down the GitHub > > repositories is already a good idea, maybe point people to > > > > https://libvirt.org/hacking.html > > > > in the meantime? > > As danpb mentions in the cover letter, CONTRIBUTING.md should be easily > discoverable on GitLab. We [0] should somehow put the brief instructions > there (like README-hacking) and not scare drive-by contributors with > the giant hacking.html. The problem with hacking.html is that it's a catch-all location that where a hodgepodge of concepts, which are related to various degrees, are documented: * various resources related to libvirt development, such as the primary git repository and the libvirt project on Zanata; * how to write good commit messages; * how to split changes into multiple commits; * other requirements, such as having DCO information; * how to run the test suite; * how to fix issues reported by valgrind; * how to send patches to libvir-list; * which languages are appropriate for new code; * what's our code style; * which GLib APIs should be used instead of libvirt-specific APIs that in most cases have been dropped already; * governance rules; all of it sprinkled with useful tips such as which options to use when running 'git diff'. No wonder it's overwhelming. I think we should rethink how we organize this information. For example, while the fact that git-publish should be used to post patches is, at least until we complete the move to GitLab, critical information to new contributors, but detailed steps for setting up mail delivery in git could live in a separate guide linked to from the main document, so that only those who are not already familiar with a mail-based development workflow need to access it; along the same line, how to run the test suite should be documented prominently but how to solve issues reported by valgrind doesn't. Of course the biggest offender is the coding style, which takes up most of the page. That could be split off to a separate page too, under the IMHO sane assumption that even someone unfamiliar with the codebase will naturally get very close to adhering to it through a combination of looking at existing code and addressing the issues reported by 'make syntax-check'; in the longer run, we should really invest some time building a clang-format profile that approximate our current coding style and just require that all contributions go through that tool, thus making the page mostly obsolete. Anyway, back to CONTRIBUTING.md specifically: once we have improved and trimmed down hacking.html (contributing.html?) to a reasonable size, we can simply link to it. I don't think that's a strict dependency, however, and while our current hacking.html is clearly suboptimal I'd rather have issues/PRs locked down and directing developers to it than the current status quo.