Here is a draft for the monthly report to be published in a few days. Feel free to edit/add, it’s a wiki
title = “Forge federation: monthly report 4/9”
date = “2021-06-24T08:07:31+02:00”
tags = [“report”]
categories = [“fedeproxy”]
banner = “img/banners/fedeproxy-logo.png”
The July 2021 monthly update videoconference will be held July 29th 5:30pm, 2021 and is open to everyone.
There is nothing user facing yet but the code is running as shown in the output of the integration tests. It relies on fixtures that target each available forge (Gitea and GitLab at the moment) as well as fixture factories to create test users that can be re-used between tests.
The discussions related to the representation of users that exist on multiple forges as well as discussions with people running a Gitea forge led to the conclusion that security was an requirement, even for experimental purposes. The operations that were previously carried out with a root token in the integration tests are now carried out by unprivileged users. The various incarnations of a given user on federated forges are represented by identities that are loaded from the DVCS when Fedeproxy is initialized.
Where possible tests are implemented using the interface rather than the concrete implementation: for instance test_forge.py exclusively rely on the forge interface. The concrete tests are only for forge features for which it is yet unclear what the interface will be, for instance the fork feature of Gitea).
Although the initial idea was to use the GitLab format to store Issues, it turned out to be hazardous and a new format was boostrapped, with minimal documentation. It is limited to issues and comments and used to implement the load/save functions use this format for the issues of a project.
The first release of fedeproxy was published June 30th and is in alpha stage. The next release is scheduled for July 31st. See the release notes for details about what they provide. The documentation is now configured to be published for each release.
More technical details can be found in the development category of the forum.
Pierre-Louis participated to the following DAPSI sessions:
- Collective Training: Powerful pitching and get your pitch right
- Trustworthiness & Data sovereignty: the International Data Spaces as an Example
Loïc participated to the following DAPSI session: An introduction to GDPR & data subject’s rights.
Resources and organizations that could help were explored and the conclusion was published as a blog entry and on the OSD forum. The next action will be to reach out to underrepresented groups to find early adopters.
The Key Performance Indicators required by the organization funding fedeproxy were received and include diversity (page 8). The documented efforts to improve diversity will therefore be part of the grading, a pre-condition for 1/3 of the money to be released.
Details on the work done to foster diversity are available in the forum.
Loïc was onboarded as a maintainer of the Gitea based, Chapril forge and will spend two hours a week helping with the maintenance. This effort is accounted as time spent for the benefit of fedeproxy because it will provide an opportunity to deploy and monitor experimental versions of fedeproxy against the Chapril forge. These motivations were disclosed to the current maintainers of the Chapril forge in the introduction message proposing help.
Pierre-Louis volunteered too for maintainership of the Chapril forge. The onboarding happened at the end of July and takes half a day. Before that, Pierre-Louis followed two
Chapril get together meetings (17/07 and 24/07).
Gitea is more amicable to the idea of a native implementation of federated features in the near future than GitLab or GitHub. However the discussions started months ago are not making progress and no federated features are currently included in the 1.16 plan initiated in July for the next Gitea release. A 5K€ bounty was proposed but did not trigger any proposal. A grant application is being worked on to fund this work. The time spent by Loïc on this grant application is accounted as time spent for the benefit of fedeproxy because the ultimate goal is that it becomes redundant when forges natively implement federation.
An additional effort has been made to support Mercurial and acknowledged that DVCS is not synonym of Git. It is facilitated by the availability of Heptapod docker images which can conveniently by used to replace the GitLab fixture and provides both Git and Mercurial support. Since Heptapod is also a friendly fork of GitLab, it is the path of least resistance to contribute changes to GitLab: a patch against Heptapod has a higher chance of being reviewed than a patch against GitLab because the developers support fedeproxy from the beginning. A positive review of a patch against Heptapod likely means the patch has a better chance of being taken into account by the GitLab developers.
A communication plan was drafted and will be set in motion in a few weeks. The collaboration initiated with existing forges (Heptapod and Chapril) led to discussions that helped define their expectations with regard to fedeproxy. They may be inclined to relay messages related to fedeproxy if they are met.
The June 2021 monthly event happened, with Arnold, Pierre-Louis and Loïc. It continued the discussions about multi forge web services and seeded the idea of reaching out to underrepresented groups when looking for early adopters. It was a good idea and will happen sooner than expected.
The July 2021 monthly event will happen June 31st.
Because of exceptional circumstances (the pandemic) Pierre-Louis and Loïc will have an excess of funds (because there will be very little travel expenses) that may be directed towards implementing federation in Gitea. The total amount is 5,000€ and will be released to developers who claim merged pull requests in Gitea that contribute to federation.
A HOWTO was published explaining how to make an earmarked donation to fedeproxy via liberapay.