5:31 p.m.
Hi Maciej,
Sorry for being late to the party. Here are my thoughts on this topic.
On Thu, 2020-07-23 at 00:26 +0200, Maciej Delmanowski wrote:
Both models assume that a large number of people participate in the
project,
so at the moment we don't have to worry about which path to take. But I
think that the model used by the kernel developers fits better for a project
such as DebOps, which is developed in the open, shared space by a dedicated
community.
Agreed.
Use of 'git' as the version control system also gives us an
advantage here
- since the project is maintained in a monorepo, we can leverage the
mechanism of codeowners[5] to give interested people "ownership' of parts of
the code. In such case they would take over reviews and maintenance of
selected parts of the codebase. That file is currently present in the DebOps
monorepo[6] but is not really used for anything - I'm keeping track on all
changes and nobody so far volunteered to help with reviews of a specific
role or part of the codebase, at least since that mechanism was added. If
you want to be included to easily keep track of parts of the repository that
interest you, let me know. In such case I'll wait with merging a given pull
request for your review.
I've started 'Watching' the monorepo which causes GitHub to send me emails of
all discussions and new PRs. I'll try to chip in a review here and there.
There are a few roles that I would like to become codeowner of so that I can
review changes before they are merged. I'll submit a PR to add myself to the
CODEOWNERS file.
At the moment in our contributor workflow[7] we mandate use of GPG
signatures in git commits and advocate for clean and concise git commit
messages[8], but that's rarely enfoorced. The output of 'git log -p --no-
merges' leaves a lot to be desired in the context of easily readable and
clean commits, and I'm guilty of it as well - partially because I'm trying
to record changes in the official Changelog file and I don't want to simply
repeat the note from the Changelog in the commit message. So now I wonder,
if a better focus on cleaner git commits in lieu of less verbose Changelog
file would work better in the long run? How many of you rely on the
Changelog to keep track of important changes (the upgrade notes are of
course another matter and should stay as they are)?
I always thorougly read the changelog and upgrade notes every time I update
DebOps to a new minor/major version, or the commit messages when updating to a
new patch version. Then I proceed to carefully running the new playbooks
against my infrastructure, first testing them out with the --check flag.
The changelog is great at showing what has changed from a user's perspective:
what changes to a role have been made, what bugs have been fixed, what has
been added or removed. Commit messages are different in that they are written
for developers and describe changes that may not be visible or interesting to
users. These commit messages are nontheless important and care should be taken
to write them properly.
So in my opinion we should continue with carefully writing changelog entries,
and try to improve our commit messages as well.
Or alternatively, should I point out all the issues in the pull
request
before the pull, then the original authors could rework the patches, rebase
where necessary and provide a set of clean commits? To be honest that seems
a bit imposing to me, but if more and more people are relying on my
judgement about what gets into the codebase, perhaps my standards need to
be higher?
This I think is the best approach. It ensures high standards in the master
branch, doesn't mess with commit signatures in any way, and is useful for the
commit author. I know I found your feedback useful.
Imre