2:12 p.m.
On lip 23, Tasos Alvas wrote:
I feel that with the current number of contributors, we're more
likely to
see results by concentrating on what each person can offer than dreaming up
an organization to last the ages.
The layers approach certainly applies to merging itself; I'm in no hurry to
see more people having that access.
The stakeholder model is pretty much what we organically have right now.
So that means the current project structure and stuff we're doing is fine
as-is for now? I can go with that, let's see where it will be in a few years,
then we can reevaluate when necessary, or when people start complaining.
In terms of actual roles, there's bound to be a ton of overlap.
Such a separation already exists in a way in the `site` playbook, at least
in
the ways that matter to implementation. I don't think this should leave a
footprint outside `CODEOWNERS` and maybe the doc.
Apart from stakeholder groups, which would exist unofficially anyway,
gruntwork groups such as `doc` and `code-style` could offer opportunities
for new devs to make themselves useful and familiarize themselves with the
project. I have seen this kind of work successfully used as an onboarding
tool in Godot.
Currently the codeowners file uses "teams" for such purpose, but these teams
are defined on GitHub which I don't necessarily like - this makes the monorepo
bound too much to GitHub itself which I would prefer to avoid. I think what we
can do is define these groups in the comment section of the codeowners file,
then people in each section can be added to the apropriate file patterns such
as roles. Of course more than one person can be marked as a codeowner, so we
can definitely have a diverse overlap.
I wonder if something similar to the CREDITS file[1] should also be in the
repository? Copyright lines required in each file kind of inform who is the
author of a given file, but maybe some more details about each person involved
would help strenghten the community a bit? I don't really care about people's
home addresses (also, GDPR nightmare), just some info where everybody works
and what their interests are should be interesting. Should I set it up?
[1]: https://github.com/torvalds/linux/blob/master/CREDITS
> GPG signatures on git
Frankly, @drybjed has the only signature that matters to the outside world.
I find it both fun and useful to sign our commits for internal verification,
but as an end user my trust is based on the signed merge.
I would think the contributors' sigs have fulfilled their purpose when they
reach @drybjed and a signed release tag by him might be all that's needed on
the user side.
I'm mentioning this purely in the spirit of not letting it stand in the way
of getting things done. As long as the actually useful functions of trust
and attribution do not break, it is there to serve development.
I see... True, I guess after the commit is merged, only the signature of the
merge matters. So I guess it's fine if I override somebody else's GPG
signature with mine as long as their authorship information stays in the
commit. This has been happening already with commits that are cherry-picked to
stable releases, but that couldn't be helped - they were new commits, not
something merged via another commit.
> Give interested people 'ownership' of parts of the
code.
I think authors of roles should automatically go there and opt out later if
they choose. It would set an expectation for maintenance that I think should
go together with the rest of the debops code standards.
Sounds like a good idea. This probably should be mentioned in the contributor
guide, just have it clearly visible. if somebody doesn't do it, I'll try to
add them manually as a codeowner of a role, that way they will at least be
notified by GitHub when somebody messes with their code.
As for accepting merges - when I see changes in parts I'm not familiar with
I always try and reach out for the role authors when they are around.
I suppose that this would have to be with a timeout in case that people are no
longer interested in DebOps for various reasons.
> Cleaner git commits in lieu of less verbose Changelog file
Users rely on the changelog. I guess it would be cute to autogenerate it
from git and I really like the fact that it would enforce a style guideline,
but a good commit message is not directed to the same _audience_.
Plus it would get full of cruft like "fixed typo in obscure_task", just
written well.
Agreed, that's why keepachangelog.com project discourages doing that and
promotes more personalized Changelogs. I guess it will have to stay then, at
least for now.
> 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.
You make the spec. It is all the rest of us have to go on.
Being up-to-spec with a project like debops is a net benefit to anyone
receiving your guidance. Learning is one of the core reasons people
volunteer to contribute to free software. I was super happy when you made
suggestions on my first PR and then let me fix it.
I will do more through reviews with suggestions then.
Now, having to say it twice instead of pointing at a doc is an
issue.
Searching the issues and PRs themselves for this history on github can get
pretty messy too.
I think that documenting the specification is not enough, nobody reads the
user manual. We need to add custom rules for the existing linters like
ansible-lint, that should help enforce code structure automatically even
before it gets committed to the repository. Passing through the linter should
be say, 80% chance that your code gets accepted. Debian has Lintian which is
a huge help th the contributors, using a similar approach in DebOps should be
good for us as well.
-- Maciej