3:25 p.m.
On Aug 26, Robin Schneider wrote:
>> - The role maintainer model has to be given up (at least
privilege
>> wise). Either one is a main developer of DebOps and has access to
>> everything or one has no rights.
>
> On the contrary, with just one repository, you can fork it on GitHub and gain
> access to everything that way. Your changes could then be pulled to the main
> repository from your fork. If your fork is popular enough that users start
> using it instead of the main DebOps repository, you win.
I agree with ganto. Write privileges could only be given on a all or
nothing base. Some git receive hook should be put in place to limit this.
I was fine with having no write access to certain parts of the
project because I don’t/did not need them (principle of least privilege).
I think that the "write access problem" is strictly linked to how the DebOps
project is maintained on GitHub in an organization. With switch to one
repository, when you clone it, you have access to the entire repository in
your own fork.
Just for comparsion of how Linux kernel is maintained this way - there's
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git
repository which is maintained by Linus, but there also hundreds of other git
repositories with the kernel, maintained by different people, available at
https://git.kernel.org/pub/scm/linux/kernel/. The one you "follow" depends on
your choice. So, there could be a https://github.com/ypid/debops/ fork with
ypid's changes, and https://github.com/ganto/debops/ fork with ganto's
changes, and https://github.com/drybjed/debops/ fork with drybjed's changes.
These forks are publicly available and users can choose to follow one of them,
or cherrypick and combine stuff in their own fork.
Now, what about https://github.com/debops/debops/ fork? With the current
DebOps Policy in place, write access would be given to the current project
Developers, ie. drybjed and ypid. The Developers (I imagine) would first put
the changes in their own forks, and then they could be merged in the
debops/debops tree after through testing. To be honest, with single git
repository instead of multiple, the need for an entire separate
'debops/debops' fork kind of falls apart in my mind. Right now it should be
used as a staging point to bring everything back together into a single
repository. After that, when the new repository is forked by multiple people,
we can see how it works out.
>> - It's harder to follow development and see issues of
individual roles
>> as everything will be mixed together.
>
> I think that this ties with the case where multiple roles need to be modified
> together to work properly (think project-wide firewall changes, or the recent
> Postfix updates). In the current model, each role requires a separate PR to
> handle the required changes, in one repository model all the needed changes
> could be grouped together in one PR, developed over time to encompass
> everything that's involved in that PR, and committed at once.
>
> Looking at issues for individual roles could be handled by properly using
> labels and/or tagging issue titles. In the current model I stopped using
> GitHub issue labels altogether because each repository needed to have them set
> up separately. I guess that this could be handled by writing scripts that
> manage labels in all DebOps repositories via GitHub API, but that never
> happened (lack of manpower, I suppose).
There are both pros and cons here. I just want to emphasize one con for me:
It would be much more difficult to watch only parts of DebOps. For example, I
maintain debops.cryptsetup and a few others and would need to watch for issues
and PRs.
Getting notified for all PRs/issues of DebOps directly does not scale.
I guess the easiest solution would be a PR/issue template where contributors
need to CC the role maintainer. That should solve it.
No need for that - https://help.github.com/articles/about-codeowners/.
In short, it's a file in the root directory of the repository that specifies
what files or paths are maintained by who, and when a new PR is published that
changes one of these files, a person is added as a reviewer of that PR. Of
course this works only on GitHub, but could be scripted elsewhere. Linux
kernel uses a similar system with the MAINTAINERS file, which was an
inspiration for the CODEOWNERS on GitHub.
When the merge is done, I would like to do a review in that sense
that nothing
of the role code was changed from the individual git repos (which I reviewed and
implicitly signed) to one repo and then create a signed commit. This way, the
merge which might be difficult for others to review is at least signed by two
independent parties. Scripts should be used for the merge where possible and it
would be nice if those scripts would also help with reviewing an already completed
merge.
For now my plan is to resolve issues and pull requests in all roles and
playbooks on GitHub. When there will be no more issues, I want to merge the
roles and playbooks into one repository directly, preserving the commit
history of each. The way it seems best to work is to first move all of the
role files from the root of its repository to 'ansible/roles/' directory, then
fetch the commits from the role repository to the destination repository and
merge with 'master'. The same with the debops-playbooks repository and all the
others.
When everything is merged in one repository, and hopefully is still somewhat
usable by Ansible, the result will be tagged as v0.9.0. After that, we can
start working on merging all of the role documentation together, changelogs,
and clean up. When it's all done, I hope that there will be a v1.0.0 release.
I just saw that drybjed already initialized the new repo
(https://github.com/debops/debops). Now the rename of the debops tools to
debops/debops-tools pays off :)
Yes, that was a good move. Right now I need to focus on finishing the Postfix
redesign though, it's long overdue.
Cheers,
Maciej