Decision: language choice for the implementation of fedeproxy

Governance and decisions
#1

Decision proposal:

https://fedeproxy.eu/blog/2021/10/17/go/

Consensus period: 2021-10-24T22:00:00Z → 2021-11-08T23:00:00Z

Approved by consensus:

Bonjour,

It appears I made a mistake in the decision process that led to switching to Go. By engaging the discussion end of August and based on the lack of feedback I got over the weeks that followed, I assumed nobody was really interested and it was up to me.

And instead of presenting the rationale for the switch and waiting for a period of a few weeks to get a consensus, I declared the decision was final. Since it is a decision that impacts every developper involved in the project, that was not the way to do it. It was contrary to the principles of horizontality that are dear to me and fundamental to the project. I apologize for that mistake and ask for forgiveness to the people who felt wronged by my behavior.

I hereby re-open the decision and genuinely consider the option of keeping python for the implementation, with an open mind. The decision to switch to Go is very new and there is nothing blocking a revert. Nothing definitive happened in the past few weeks.

So… here we go :slight_smile: If people have objections on this switch to Go, as explained in this blog post, please speak up! If there is no objection within two weeks, the decision will be to switch to Go.

Cheers

Community building and channel feedback
DRAFT: monthly report, November 2021
On transparency, funding and efficiency
Codebase evolution: fedeproxy python and Go
A guide to forgefriends governance
My forgefriends development strategy 2022-2023
DRAFT: monthly report, September 2022
DAPSI call deadline 23/11/2021
#2

During the next two weeks I’ll keep contributing to Gitea, because it makes sense whatever the language choice is for fedeproxy in the end. I will however refrain from planning anything for fedeproxy related to its development because it depends on the outcome of this discussion. A concrete example of Gitea contribution is the go-fed integration. And a concrete example of fedeproxy development is the CI in lab.fedeproxy.eu.

#3

Regarding our proposed DAPSI goals and the DAPSI schedule (page 6): isn’t this switch a riskier way to achieve these goals? It looks like the switch implies more unknowns.

This greater risk worries me since a failure to achieve our goals would impact the following grant proposals. It looks less risky to follow the initial plan, then to switch and then to do a rewrite. This would use more resources and cost more, but considering the overall goal - the fedeproxy project being dissolved in the forges - it looks like a small setback.

I think that the new proposed plan is a good way to dissolve Fedeproxy into Gitea (and to implement a fedeproxy service outside of Gitea), but I would rather the acceleration of the Gitea federation development was not a burden for the initial roadmap. Should not this switch be performed once the initial plan has been implemented?

On another note, federation was implemented for pagure (https://forum.fedeproxy.eu/c/development/forgefed/18) five months ago. This development was funded by an NLNet grant and its result is an extension not hosted within the Pagure repository. Since this project already exists, could not fedeproxy be “extracted” from this project (instead of being dissolved into it)? I mean, is there any way we could reuse it?

#4

I think it actually is less of a risk because it requires less work in the short term, as explained in the blog post by listing the Gitea features that can be re-used by fedeproxy.

As time passes switching the language four months from now becomes a lot harder, primarily because:

  • The code base grows and developers (including myself) naturally become more and more reluctant to abandon it, even for good reasons.
  • As more features are implemented in fedeproxy which are redundant with what Gitea already has, not only is this effort wasted, it also lowers the incentive to reuse the Gitea codebase (why reuse something that’s already there?)
  • fedeproxy will be deployed and have users: migrating the deployed servers and the users from a codebase to another is additional work and a significant one

Since swithcing to Go is currently less risky than sticking with the current codebase and that delaying the decision actually increases both risks and amount of work, I think it would be self defeating to delay. It could make sense to never switch to Go, but I can’t see any upside in delaying.

I studied the code and in my opinion it is not a good fit, although it has been a source of inspiration for the current implementation of fedeproxy. The primary reasons are:

  • It is still in experimental stage (just as fedeproxy at the moment)
  • It is not actively developped (last commit was five months ago)
#5

@pilou does that answer your questions and appease your concerns?

#6

A post was split to a new topic: SemApps

#7

As a developer - like you - of the horizontal Fedeproxy community, your choice (as a developer of the Fedeproxy community) to a posteriori follow the community manifesto is a good one.

As a DAPSI beneficiary, I trust you - the DAPSI coordinator - so that the goals for which we are committed together are achieved.

#8

It has been over two weeks since the proposal was submitted and there was no objection: it is decided then :slight_smile: