[AGREEMENT] Forgejo becomes a hard fork of Gitea #58

earl-warren commented 2024年01月14日 22:07:42 +01:00

• If you agree 👍 this comment
• If you have concerns, add a comment explaining what they are in a dispassionate and rational way
• If you have no opinion 👀 this comment

---

The Forgejo development workflow currently is a soft fork of Gitea. It is a set of commits carefully maintained and cherry-picked weekly on top of the Gitea development branch. While this has worked well since Forgejo inception, it is now time for Forgejo to change to become a hard fork. It will evolve independently of Gitea but will cherry-pick commits that contain bug fixes. This is the development model most Free Software developers expect when a project forks from another project.

This proposed agreement is the outcome of a discussion where a significant number of active Forgejo contributors agreed it should be a decision that is made in accordance to the decision making process. Once implemented, there is no turning back and it will impact the future of Forgejo as a whole.

The agreement will be documented on 14 February 2024 at the earliest, possibility later if concerns need to be addressed.

Should an agreement be reached, it will lead to an implementation explained in "When" and "How". In the meantime Forgejo contributors can get familiar with the new workflow as explained in the "Transition" phase, there is no blocker. A hard fork is ultimately a judgment call: each Forgejo community member has to decide for themselves if the time is right (see the "Timing" section below) and weigh the advantages of this workflow (see the "Benefits" section below) and its disadvantages (see the "Loss" section below).

When

After the next major release (v1.22) or March 1st, whichever comes first. Because it is when the release team has more time to work on it, being done with the preparation of the major release.

How

• All feature branches are merged into the forgejo branch one last time
• The developer workflow is updated to remove the part on feature branches
• A blog post is published to announce Forgejo will eventually no longer be a drop-in replacement of Gitea
• Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (for instance when it is decided to implement compatibility / interoperability in Forgejo)

Interoperability

The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. Existing APIs at the time of the fork are public, and changing them is a breaking change, which has to be evaluated very carefully, and not done lightly. Future APIs should similarly be evaluated, and Forgejo will try to remain compatible with Gitea. However, Forgejo shall also use their own judgement whether to implement an API or not, and how - with the previous goals in mind.

Transition

The transition phase before the hard fork is implemented starts 14 January 2024 and allows Forgejo contributors to get familiar with the new workflow. There are a number of parts in Forgejo that already are independent from Gitea and they can be a training ground to prepare for the hard fork.

After discussions about six months ago the maintenance for stable branches switched from rebasing to cherry-picking. To get familiar with how cherry-picking versus rebase is done check the logs of the stable branches releases starting with v1.20 and v1.21.

The documentation is hard forked and maintained differently: it changed very significantly and cherry-picking is rarely possible. Instead modifications found in Codeberg or Gitea are manually copy/pasted on a regular basis, when and if their content is relevant to Forgejo.

The Forgejo runner is also hard forked and demonstrated another pattern. The Gitea runner has not changed much in the past six months and cherry-picking the few commits it contains has been very little work. It is comparable to what would happen in areas of Gitea that do not change much.

Timing

• Forgejo grew to have more contributors (see the last section of each monthly update)
• There is enough funding
• There are enough resources (hardware, etc.)
• Forgejo governance & project organization is complete
• It would not hinder a cooperation that does not exist
  • Only the most trivial bug fixes originating from Forgejo have been successfully contributed to Gitea, features or even security fixes are either stalled, re-written or rejected.
  • Gitea contributors never cherry-picked a commit from Forgejo
  • A few Gitea contributors are active in Forgejo spaces, but their participation is such that it would not be negatively impacted by this decision

Benefits

Primarily

• It allows to not be impacted by regressions introduced in Gitea (see the blog post about the storage regressions, the pull request that refactored the PAT in v1.20 which had unspecified side effects and led to the recommendation to re-create all tokens and the pull request that implements actions which is still mostly untested today)

Secondarily

• It is more friendly to casual contributors compared to the current workflow
• It allows to make architectural changes
• It allows to not be impacted by Gitea shady security behavior

Loss

Primarily

• Bug fixes in Gitea become increasingly more difficult to integrate in Forgejo
• Forgejo will eventually stop being a drop-in replacement

Secondarily

• Features introduced in Gitea become increasingly more difficult to integrate in Forgejo

---

Update 21 January 2024

The following is added

Interoperability

The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. Existing APIs at the time of the fork are public, and changing them is a breaking change, which has to be evaluated very carefully, and not done lightly. Future APIs should similarly be evaluated, and Forgejo will try to remain compatible with Gitea. However, Forgejo shall also use their own judgement whether to implement an API or not, and how - with the previous goals in mind.

---

Update 26 January 2024

The following is added

How

• Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (for instance when it is decided to implement compatibility / interoperability in Forgejo)

* If you agree 👍 this comment * If you have concerns, add a comment explaining what they are in a dispassionate and rational way * If you have no opinion 👀 this comment --- The [Forgejo development workflow](https://forgejo.org/docs/v1.21/developer/workflow/) currently is a soft fork of Gitea. It is a set of commits carefully [maintained and cherry-picked weekly](https://codeberg.org/forgejo/forgejo/milestones?state=closed&q=cleanup) on top of the Gitea development branch. While this has worked well since Forgejo inception, it is now time for Forgejo to change to become a hard fork. It will evolve independently of Gitea but will cherry-pick commits that contain bug fixes. This is the development model most Free Software developers expect when a project forks from another project. This proposed agreement is the outcome of [a discussion](https://codeberg.org/forgejo/discussions/issues/96) where a significant number of active Forgejo contributors agreed it should be a decision that is made in accordance to the [decision making process](https://codeberg.org/forgejo/governance/src/branch/main/DECISION-MAKING.md). Once implemented, there is no turning back and it will impact the future of Forgejo as a whole. The agreement will be documented on 14 February 2024 at the earliest, possibility later if concerns need to be addressed. Should an agreement be reached, it will lead to an implementation explained in "When" and "How". In the meantime Forgejo contributors can get familiar with the new workflow as explained in the "Transition" phase, there is no blocker. A hard fork is ultimately a judgment call: each Forgejo community member has to decide for themselves if the time is right (see the "Timing" section below) and weigh the advantages of this workflow (see the "Benefits" section below) and its disadvantages (see the "Loss" section below). ## When After the next major release (v1.22) or March 1st, whichever comes first. Because it is when the release team has more time to work on it, being done with the preparation of the major release. ## How * All [feature branches](https://forgejo.org/docs/v1.21/developer/workflow/#feature-branches) are merged into the forgejo branch one last time * The [developer workflow](https://forgejo.org/docs/v1.21/developer/workflow/) is updated to remove the part on feature branches * A blog post is published to announce Forgejo will eventually no longer be a drop-in replacement of Gitea * Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (for instance when it is decided to implement compatibility / interoperability in Forgejo) ## Interoperability The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. Existing APIs at the time of the fork are public, and changing them is a breaking change, which has to be evaluated very carefully, and not done lightly. Future APIs should similarly be evaluated, and Forgejo will try to remain compatible with Gitea. However, Forgejo shall also use their own judgement whether to implement an API or not, and how - with the previous goals in mind. ## Transition The transition phase before the hard fork is implemented starts 14 January 2024 and allows Forgejo contributors to get familiar with the new workflow. There are a number of parts in Forgejo that already are independent from Gitea and they can be a training ground to prepare for the hard fork. After [discussions about six months ago](https://codeberg.org/forgejo/website/pulls/296) the maintenance for stable branches switched from [rebasing to cherry-picking](https://forgejo.org/docs/v1.21/developer/workflow/#stable-branches). To get familiar with how cherry-picking versus rebase is done check the logs of the stable branches releases starting with [v1.20](https://codeberg.org/forgejo/forgejo/milestones?state=closed&q=Forgejo+v1.20) and [v1.21](https://codeberg.org/forgejo/forgejo/milestones?state=closed&q=Forgejo+v1.21). The [documentation](https://codeberg.org/forgejo/docs) is hard forked and maintained differently: it changed very significantly and cherry-picking is rarely possible. Instead modifications found in Codeberg or Gitea are manually copy/pasted on a regular basis, when and if their content is relevant to Forgejo. The [Forgejo runner](https://code.forgejo.org/forgejo/runner) is also hard forked and demonstrated another pattern. The Gitea runner has not changed much in the past six months and cherry-picking the few commits it contains has been very little work. It is comparable to what would happen in areas of Gitea that do not change much. ## Timing * Forgejo grew to have more contributors (see the last section of [each monthly update](https://forgejo.org/tag/report/)) * There is [enough funding](https://codeberg.org/forgejo/sustainability/#2023) * There are [enough resources](https://forgejo.org/docs/v1.21/developer/infrastructure/) (hardware, etc.) * Forgejo [governance](https://codeberg.org/forgejo/governance#meta) & [project organization](https://forgejo.org/docs/v1.21/developer/) is complete * It would not hinder a cooperation that does not exist * Only the most trivial bug fixes originating from Forgejo have been successfully contributed to Gitea, features or even security fixes are either [stalled, re-written or rejected](https://github.com/go-gitea/gitea/pulls/earl-warren). * Gitea contributors never cherry-picked a commit from Forgejo * A few Gitea contributors are active in Forgejo spaces, but their participation is such that it would not be negatively impacted by this decision ## Benefits ### Primarily * It **allows to not be impacted by regressions introduced in Gitea** (see [the blog post about the storage regressions](https://forgejo.org/2023-09-monthly-update/#fixing-s3-configuration-bugs-and-regressions), the [pull request that refactored the PAT in v1.20](https://github.com/go-gitea/gitea/pull/24767) which had unspecified side effects and led to the recommendation to re-create all tokens and [the pull request that implements actions](https://github.com/go-gitea/gitea/pull/21937/files) which is still mostly untested today) ### Secondarily * It is more friendly to casual contributors compared to [the current workflow](https://forgejo.org/docs/v1.21/developer/workflow/) * It allows to make architectural changes * It allows to not be impacted by [Gitea shady security behavior](https://codeberg.org/forgejo/website/issues/392) ## Loss ### Primarily * Bug fixes in Gitea become increasingly more difficult to integrate in Forgejo * Forgejo will eventually stop being a drop-in replacement ### Secondarily * Features introduced in Gitea become increasingly more difficult to integrate in Forgejo --- Update 21 January 2024 The following is added ## Interoperability The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. Existing APIs at the time of the fork are public, and changing them is a breaking change, which has to be evaluated very carefully, and not done lightly. Future APIs should similarly be evaluated, and Forgejo will try to remain compatible with Gitea. However, Forgejo shall also use their own judgement whether to implement an API or not, and how - with the previous goals in mind. --- Update 26 January 2024 The following is added ## How * Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (for instance when it is decided to implement compatibility / interoperability in Forgejo)

gwymor commented 2024年01月15日 02:31:10 +01:00

As a happy Codeberg user I appreciate that Forgejo always has all the functionality of Gitea, along with added features/fixes of its own, and that if I contribute a feature to Gitea, it will eventually make it to all the Gitea and Forgejo instances I interact with. I would hope to avoid such a hard fork and subsequent divergence of functionality, or Forgejo lacking beneficial new features Gitea has (though I can sympathize with the difficulty of maintaining a long-term soft fork).

For example, it would be quite unfortunate if this divergence meant that federation efforts would be duplicated and couldn't be easily shared between Forgejo and Gitea. I think it's in our best interest for federation to be widely supported, and it would be disappointing if I could make use of federation features here on Codeberg, but couldn't contribute to Gitea-hosted projects, or vice versa, because the code cannot be easily shared.

As a happy Codeberg user I appreciate that Forgejo always has all the functionality of Gitea, along with added features/fixes of its own, and that if I contribute a feature to Gitea, it will eventually make it to all the Gitea *and* Forgejo instances I interact with. I would hope to avoid such a hard fork and subsequent divergence of functionality, or Forgejo lacking beneficial new features Gitea has (though I can sympathize with the difficulty of maintaining a long-term soft fork). For example, it would be quite unfortunate if this divergence meant that federation efforts would be duplicated and couldn't be easily shared between Forgejo and Gitea. I think it's in our best interest for federation to be widely supported, and it would be disappointing if I could make use of federation features here on Codeberg, but couldn't contribute to Gitea-hosted projects, or vice versa, because the code cannot be easily shared.

earl-warren commented 2024年01月15日 13:15:15 +01:00

Feature wise it will be a loss, no doubt.

Regarding federation it is different because the very purpose of the implementation is to establish a dialog with all forges, not to focus on Forgejo alone. This is what I work on daily in Forgejo and I'll contribute that feature to Gitea if that's the only thing I do. Whether they take it or not is then their decision but it won't be because the code is missing, it will be a non-technical decision.

Does that address your concern? If it does not because it is a little too vague, I'm happy to go into more details regarding how I plan to achieve this.

Feature wise it will be a loss, no doubt. Regarding federation it is different because the very purpose of the implementation is to establish a dialog with all forges, not to focus on Forgejo alone. This is what I work on daily in Forgejo and I'll contribute that feature to Gitea if that's the only thing I do. Whether they take it or not is then their decision but it won't be because the code is missing, it will be a non-technical decision. Does that address your concern? If it does not because it is a little too vague, I'm happy to go into more details regarding how I plan to achieve this.

Ghost commented 2024年01月15日 13:40:18 +01:00

My work in 2024 will be on https://f3.forgefriends.org/ to ensure data portability between forges, a building block for federation. It is a go package independent of Forgejo or Gitea. It will support Forgejo and Gitea first because the differences are very small and the language is the same. It is also designed to be used by GitLab, with a Ruby module re-using the gof3 package binary. And also as a Python module using the same. Very similar to how SQLite is integrated in those interpreted languages.

In short: making sure federation works between Forgejo and Gitea is the low hanging fruit and I'm really not worried about it. The difficult part is GitLab and GitHub.

My work in 2024 will be on https://f3.forgefriends.org/ to ensure data portability between forges, a building block for federation. It is a go package independent of Forgejo or Gitea. It will support Forgejo and Gitea first because the differences are very small and the language is the same. It is also designed to be used by GitLab, with a Ruby module re-using the gof3 package binary. And also as a Python module using the same. Very similar to how SQLite is integrated in those interpreted languages. In short: making sure federation works between Forgejo and Gitea is the low hanging fruit and I'm really not worried about it. The difficult part is GitLab and GitHub.

forgejo-moderation commented 2024年01月15日 16:52:53 +01:00

A message from an account created to circumvent a ban from Forgejo spaces was deleted, send a mail to moderation@forgejo.org for more information.

A message from an account created to circumvent a ban from Forgejo spaces was deleted, send a mail to moderation@forgejo.org for more information.

gwymor commented 2024年01月16日 04:46:14 +01:00

Does that address your concern? If it does not because it is a little too vague, I'm happy to go into more details regarding how I plan to achieve this.

That does address my concern with federation specifically, but if you want to share details on your plans, I am curious to hear! (Perhaps elsewhere so as to not derail this issue.)

It doesn't address my general concern: For me as a Codeberg end-user, the gains do not outweigh the inevitable loss of functionality from Gitea's larger development community and higher rate of features/fixes.

> Does that address your concern? If it does not because it is a little too vague, I'm happy to go into more details regarding how I plan to achieve this. That does address my concern with federation specifically, but if you want to share details on your plans, I am curious to hear! (Perhaps elsewhere so as to not derail this issue.) It doesn't address my general concern: For me as a Codeberg end-user, the gains do not outweigh the inevitable loss of functionality from Gitea's larger development community and higher rate of features/fixes.

wetneb commented 2024年01月16日 08:08:20 +01:00

At the moment, any PR merged in Gitea gets included after a week in Forgejo, without the opportunity to review it on Forgejo's side. So if we stop rebasing on top of Gitea, I wonder if it would be useful to automatically open PRs in Forgejo for each merged PR in Gitea. To me, this would have the following advantages:

• give us an opportunity to review those changes instead of them being imposed to us
• make it relatively simple to continue benefiting from changes made in Gitea when we want them
• share the workload of fixing conflicts: instead of one person having to fix all rebase conflicts at once every week, a larger team of people could take care of adapting conflicting Gitea PRs to Forgejo

The automation could be refined to ignore changes to certain files or directories (for instance, to GitHub Actions configuration files). The main downside I see is the noise in our PR list. But because those changes have been reviewed on Gitea's side, I think for a lot of them we should be able to merge them relatively quickly.

At the moment, any PR merged in Gitea gets included after a week in Forgejo, without the opportunity to review it on Forgejo's side. So if we stop rebasing on top of Gitea, I wonder if it would be useful to automatically open PRs in Forgejo for each merged PR in Gitea. To me, this would have the following advantages: * give us an opportunity to review those changes instead of them being imposed to us * make it relatively simple to continue benefiting from changes made in Gitea when we want them * share the workload of fixing conflicts: instead of one person having to fix all rebase conflicts at once every week, a larger team of people could take care of adapting conflicting Gitea PRs to Forgejo The automation could be refined to ignore changes to certain files or directories (for instance, to GitHub Actions configuration files). The main downside I see is the noise in our PR list. But because those changes have been reviewed on Gitea's side, I think for a lot of them we should be able to merge them relatively quickly.

algernon commented 2024年01月16日 12:27:23 +01:00

It doesn't address my general concern: For me as a Codeberg end-user, the gains do not outweigh the inevitable loss of functionality from Gitea's larger development community and higher rate of features/fixes.

Just because a hard fork happens does not mean that fixes and features can't be ported over from Gitea. It may take more effort as the two diverge, but that does not happen overnight, so for the foreseeable future, I do not think a hard fork would mean Forgejo would miss out on anything important happening on the Gitea side. Prime example of this: the stable releases, upon which Codeberg builds, which have effectively been a hard fork already since v1.20.

> It doesn't address my general concern: For me as a Codeberg end-user, the gains do not outweigh the inevitable loss of functionality from Gitea's larger development community and higher rate of features/fixes. Just because a hard fork happens does not mean that fixes and features can't be ported over from Gitea. It may take more effort as the two diverge, but that does not happen overnight, so for the foreseeable future, I do not think a hard fork would mean Forgejo would miss out on anything important happening on the Gitea side. Prime example of this: the stable releases, upon which Codeberg builds, which have effectively been a hard fork already since v1.20.

earl-warren commented 2024年01月16日 14:00:18 +01:00

It doesn't address my general concern: For me as a Codeberg end-user, the gains do not outweigh the inevitable loss of functionality from Gitea's larger development community and higher rate of features/fixes.

It is ultimately a judgement call that is for everyone to make. Although I have a different opinion, I cannot definitely say you are wrong. I suppose my perspective as a daily contributor working on releases and integrating Gitea changes, I'm more exposed to the impact of regressions and the consequences of the absence of testing. That plays a role in how I evaluate the situation and since those are mostly invisible to users, maybe I would side with you otherwise.

> It doesn't address my general concern: For me as a Codeberg end-user, the gains do not outweigh the inevitable loss of functionality from Gitea's larger development community and higher rate of features/fixes. It is ultimately a judgement call that is for everyone to make. Although I have a different opinion, I cannot definitely say you are wrong. I suppose my perspective as a daily contributor working on releases and integrating Gitea changes, I'm more exposed to the impact of regressions and the consequences of the absence of testing. That plays a role in how I evaluate the situation and since those are mostly invisible to users, maybe I would side with you otherwise.

earl-warren commented 2024年01月18日 18:16:04 +01:00

It doesn't address my general concern: For me as a Codeberg end-user, the gains do not outweigh the inevitable loss of functionality from Gitea's larger development community and higher rate of features/fixes.

In light of the comments above, do you concerns still stand? If they do, could you please explain in more details, with examples (like in the topic of this issue for instance), how you come to the conclusions that the gains do not outweigh the loss of functionality?

---

@gwymor I see you "thumb down" this issue. Note however this is not a vote, the Forgejo decision making process works differently. The goal is to reach an agreement where all concerns (yours included) are addressed. The outcome should be something every Forgejo community member can live with.

> It doesn't address my general concern: For me as a Codeberg end-user, the gains do not outweigh the inevitable loss of functionality from Gitea's larger development community and higher rate of features/fixes. In light of the comments above, do you concerns still stand? If they do, could you please explain in more details, with examples (like in the topic of this issue for instance), how you come to the conclusions that the gains do not outweigh the loss of functionality? --- @gwymor I see you "thumb down" this issue. Note however this is not a vote, the [Forgejo decision making process](https://codeberg.org/forgejo/governance/src/branch/main/DECISION-MAKING.md) works differently. The goal is to reach an agreement where all concerns (yours included) are addressed. The outcome should be something every Forgejo community member can live with.

6543 commented 2024年01月18日 18:40:29 +01:00

Just my two cents if I'm allowed to write here:

1. I still will try to move patches around if possible, well if i have time to do so ... (did not really had to until now :/)
2. You can call forgejo more free etc.. no problem, but gitea is not opencore and wont be in the future ... if that will hapen at some point I'm happy to help out here :)

Just my two cents if I'm allowed to write here: 1. I still will try to move patches around if possible, well if i have time to do so ... (did not really had to until now :/) 2. You can call forgejo more free etc.. no problem, but gitea is not [opencore](https://forgejo.org/compare/#only-develops-free-software) and wont be in the future ... if that will hapen at some point I'm happy to help out here :)

Ghost commented 2024年01月18日 19:16:39 +01:00

You can call forgejo more free etc.. no problem, but gitea is not opencore and wont be in the future ... if that will hapen at some point I'm happy to help out here :)

A gentle reminder that this is not a forum to debate on this topic. Please use the discussion tracker for that purpose.

> You can call forgejo more free etc.. no problem, but gitea is not opencore and wont be in the future ... if that will hapen at some point I'm happy to help out here :) A gentle reminder that this is not a forum to debate on this topic. Please [use the discussion tracker](https://codeberg.org/forgejo/discussions) for that purpose.

fnetX commented 2024年01月18日 20:35:02 +01:00

I do believe that a hard fork is inevitable. I read something inspiring about a fork of Pixelfed on the Fediverse today, and although I don't know much about the background, it is a good example of how Gitea could have behaved towards Forgejo in an ideal world.

Our time and energy and funding can be spent better than sustaining a software product that is used to advertise Open Core SaaSS services by linking to their offer from every installation.

However, I recommend that we do not rush. My proposed first step will be to change communication first:
Forgejo will become a hard fork in the future. We do not exactly know when, but it will happen. It is the definitive answer to everyone who is wondering about the state, and they can prepare accordinigly.

We should start to encourage contributions to Forgejo and experiment with different workflows, (like starting cherry-picking into release branches sooner, or merging the Gitea branches instead of rebasing them, I trust others to decide what makes sense here)

We should start to override translations with our own ones now and allow people to contribute translations without proprietary web services. The technology to override translation keys has been implemented in the past.

The hard fork will be well prepared, and happen step-by-step. But I would be always careful about the best next step and ideally gather feedback and reflect before doing the next one (not necessarily via governance decisions, but discussion issues, polls etc).

I do believe that a hard fork is inevitable. I read [something inspiring about a fork of Pixelfed on the Fediverse](https://mastodon.social/@dansup/111776677965072299) today, and although I don't know much about the background, it is a good example of how Gitea could have behaved towards Forgejo in an ideal world. Our time and energy and funding can be spent better than sustaining a software product that is used to advertise Open Core SaaSS services by linking to their offer from every installation. However, I recommend that we do not rush. My proposed first step will be to change communication first: **Forgejo will become a hard fork** in the future. We do not exactly know when, but it will happen. It is the definitive answer to everyone who is wondering about the state, and they can prepare accordinigly. We should start to [encourage contributions to Forgejo](https://codeberg.org/forgejo/discussions/issues/99) and experiment with different workflows, (like starting cherry-picking into release branches sooner, or merging the Gitea branches instead of rebasing them, I trust others to decide what makes sense here) We should start to override translations with our own ones now and allow people to contribute translations without proprietary web services. The technology to override translation keys has been implemented in the past. The hard fork will be well prepared, and happen step-by-step. But I would be always careful about the best next step and ideally gather feedback and reflect before doing the next one (not necessarily via governance decisions, but discussion issues, polls etc).

earl-warren commented 2024年01月19日 00:11:04 +01:00

However, I recommend that we do not rush.

I fully agree with that. Once engaged in a hard fork, there is no turning back. It should be done with care, sensibly and with as little disruption as possible. This agreement is binary, it is yes or no. But, although the implementation is simple, the fine details that go with it will require time and patience.

> However, I recommend that we do not rush. I fully agree with that. Once engaged in a hard fork, there is no turning back. It should be done with care, sensibly and with as little disruption as possible. This agreement is binary, it is yes or no. But, although the implementation is simple, the fine details that go with it will require time and patience.

oatbiscuits commented 2024年01月20日 08:57:09 +01:00

Forgejo's development goals and governance principles are incompatible with Gitea. Transitioning to a hard fork is inevitable, and a milestone for those interested in the health and well-being of free software.

As indicated by those who are much more familiar with the project, I agree that it should be done in a sensible, careful and with the least friction possible for Forgejo users, and those wishing to transition from Gitea.

Seeing as

A blog post is published to announce Forgejo will eventually no longer be a drop-in replacement of Gitea

will be done, I think it would be wise to announce that Forgejo is no longer a drop-in replacement when enough distinctive features (i.e: federation) have been implemented, making the switch more justifiable from a cost-benefit point of view of the admin/user.

Either way, I think clarifying when or which version will break drop-in compatibility with previous Gitea installations would be helpful. In the future, having a documented flow of migrating to Forgejo from Gitea will be helpful as well.

Forgejo's development goals and governance principles are incompatible with Gitea. Transitioning to a hard fork is inevitable, and a milestone for those interested in the health and well-being of free software. As indicated by those who are much more familiar with the project, I agree that it should be done in a sensible, careful and with the least friction possible for Forgejo users, and those wishing to transition from Gitea. Seeing as > A blog post is published to announce Forgejo will eventually no longer be a drop-in replacement of Gitea will be done, I think it would be wise to announce that Forgejo is no longer a drop-in replacement when enough distinctive features (i.e: federation) have been implemented, making the switch more justifiable from a cost-benefit point of view of the admin/user. Either way, I think clarifying when or which version will break drop-in compatibility with previous Gitea installations would be helpful. In the future, having a documented flow of migrating to Forgejo from Gitea will be helpful as well.

earl-warren commented 2024年01月20日 14:53:18 +01:00

Today Gitea users started noting a regression that is a good showcase for the main benefit of a hard fork (quoting the top message of this issue):

• It allows to not be impacted by regressions introduced in Gitea (see the blog post about the storage regressions, the pull request that refactored the PAT in v1.20 which had unspecified side effects and led to the recommendation to re-create all tokens and the pull request that implements actions which is still mostly untested today)

I wrote a message describing this particular regression that also explains in detail why it is a high impact endemic problem that would be fixed by a hard fork.

Today Gitea users started noting a regression that is a good showcase for the main benefit of a hard fork (quoting the top message of this issue): > * It **allows to not be impacted by regressions introduced in Gitea** (see [the blog post about the storage regressions](https://forgejo.org/2023-09-monthly-update/#fixing-s3-configuration-bugs-and-regressions), the [pull request that refactored the PAT in v1.20](https://github.com/go-gitea/gitea/pull/24767) which had unspecified side effects and led to the recommendation to re-create all tokens and [the pull request that implements actions](https://github.com/go-gitea/gitea/pull/21937/files) which is still mostly untested today) I wrote [a message describing this particular regression](https://codeberg.org/forgejo/discussions/issues/103) that also explains in detail why it is a high impact endemic problem that would be fixed by a hard fork.

earl-warren commented 2024年01月20日 21:01:30 +01:00

To simplify the implementation of a hard fork, when and if it happens, the migration of the translations to weblate started. It is a good thing regardless of the outcome of this agreement.

To simplify the implementation of a hard fork, when and if it happens, [the migration of the translations to weblate](https://codeberg.org/forgejo/discussions/issues/104) started. It is a good thing regardless of the outcome of this agreement.

gwymor commented 2024年01月20日 21:36:34 +01:00

In light of the comments above, do you concerns still stand? If they do, could you please explain in more details, with examples (like in the topic of this issue for instance), how you come to the conclusions that the gains do not outweigh the loss of functionality?

@earl-warren Yes. At the present, I have been satisfied with the maintainership and contribution process of Gitea for the most part, so I do not see many benefits to hard forking and the rationale listed is not strong for me. The one important-seeming benefit listed in the issue description is the ability to not be impacted by Gitea's regressions, which I haven't run into myself. If Gitea is having regressions that would be solved by better testing, have Forgejo people attempted to collaborate with the upstream project to improve testing so neither project is impacted?

@algernon While it won't be immediate, in the year or two following a hard fork it seems inevitable that Forgejo will diverge enough for it to be more and more difficult to benefit from new Gitea features/fixes, especially if one of the benefits of a hard fork is the ability to make architectural changes. Release branches are maintained for a shorter time period, so it is understandable they wouldn't run into that problem quickly. In case of a hard fork, it seems likely that Forgejo will cease to function as "everything Gitea offers, with more features/fixes", with little upside for me as a user. If Forgejo does hard fork though, @wetneb's suggestion to automatically open PRs for Gitea changes seems good.

> In light of the comments above, do you concerns still stand? If they do, could you please explain in more details, with examples (like in the topic of this issue for instance), how you come to the conclusions that the gains do not outweigh the loss of functionality? @earl-warren Yes. At the present, I have been satisfied with the maintainership and contribution process of Gitea for the most part, so I do not see many benefits to hard forking and the rationale listed is not strong for me. The one important-seeming benefit listed in the issue description is the ability to not be impacted by Gitea's regressions, which I haven't run into myself. If Gitea is having regressions that would be solved by better testing, have Forgejo people attempted to collaborate with the upstream project to improve testing so neither project is impacted? @algernon While it won't be immediate, in the year or two following a hard fork it seems inevitable that Forgejo will diverge enough for it to be more and more difficult to benefit from new Gitea features/fixes, especially if one of the benefits of a hard fork is the ability to make architectural changes. Release branches are maintained for a shorter time period, so it is understandable they wouldn't run into that problem quickly. In case of a hard fork, it seems likely that Forgejo will cease to function as "everything Gitea offers, with more features/fixes", with little upside for me as a user. If Forgejo does hard fork though, [@wetneb's suggestion](https://codeberg.org/forgejo/governance/issues/58#issuecomment-1509539) to automatically open PRs for Gitea changes seems good.

algernon commented 2024年01月20日 22:04:36 +01:00

If Gitea is having regressions that would be solved by better testing, have Forgejo people attempted to collaborate with the upstream project to improve testing so neither project is impacted?

I have tried collaborating with Gitea upstream. One pull request that updated documentation to not suggest things that cause bugs was rejected on the grounds that noone reads the docs and the problem needs to be fixed before documentation is updated. Then I went and proposed a fix for the root cause, submitted a pull request with tests, and plenty of research to support it. The pull request was discarded, and a new one was made from scratch (based on my research & suggestions, but without my code, and without any credit given), with tests that exercise the newly added functionality, but none of the code paths that were broken before (in other words, they're inadequate, while mine exercised code paths that were broken prior to the fix). I was also told by one prominent Gitea contributor that they will never collaborate with people who have anything to do with Forgejo. Another pull request of mine was ignored, with only one comment from a Gitea maintainer, who said he'd prefer another - without any reason given why. (wild guess: because the pull request came from someone with ties to Forgejo).

So, from personal experience: no, upstreaming improved testing (or anything non-trivial) to Gitea is pointless, they're not open to collaboration.

Upstreaming would also mean assigning copyright to Gitea, which is another thing I am not willing to do. I'd rather turn it around at this point: Gitea is free to cherry pick improvements and features from Forgejo (as long as they respect the relevant copyrights). Doing so would go a long way of showing they're open to collaboration.

@algernon While it won't be immediate, in the year or two following a hard fork it seems inevitable that Forgejo will diverge enough for it to be more and more difficult to benefit from new Gitea features/fixes, especially if one of the benefits of a hard fork is the ability to make architectural changes.

Yes, indeed. A year or two is hopefully enough time for people to evaluate whether they want to go with Forgejo or Gitea. It's also short enough that if things go sideways, Forgejo can work on converging back into a soft-fork.

Release branches are maintained for a shorter time period, so it is understandable they wouldn't run into that problem quickly. In case of a hard fork, it seems likely that Forgejo will cease to function as "everything Gitea offers, with more features/fixes", with little upside for me as a user.

That's a possibility. It will be its own entity, and people can choose based on what they need. If two projects have different priorities, allowing them to diverge is the logical path.

I mean, Gitea itself is a fork of Gogs, which is still maintained and developed. Did hard-forking Gitea from Gogs hurt Gitea in the long run? I don't think so. Forgejo hard-forking from Gitea might lead to a similar outcome. But we won't know until we go there.

On topic of difficulty: while diverging code bases will lead to patches not applying cleanly, the ideas will more than likely will apply for a much longer time. If Gitea has a bugfix, if it has tests, we can run a similar test against Forgejo, and see if the bug is present. Same for features. While we may not be able to cherry pick commits as-is, we can look at the code, and port it over.

> If Gitea is having regressions that would be solved by better testing, have Forgejo people attempted to collaborate with the upstream project to improve testing so neither project is impacted? I have tried collaborating with Gitea upstream. One pull request that updated documentation to not suggest things that cause bugs was rejected on the grounds that noone reads the docs and the problem needs to be fixed before documentation is updated. Then I went and proposed a fix for the root cause, submitted a pull request with tests, and plenty of research to support it. The pull request was discarded, and a new one was made from scratch (based on my research & suggestions, but without my code, and without any credit given), with tests that exercise the newly added functionality, but none of the code paths that were broken before (in other words, they're inadequate, while mine exercised code paths that were broken prior to the fix). I was also told by one prominent Gitea contributor that they will never collaborate with people who have anything to do with Forgejo. Another pull request of mine was ignored, with only one comment from a Gitea maintainer, who said he'd prefer another - without any reason given why. (wild guess: because the pull request came from someone with ties to Forgejo). So, from personal experience: no, upstreaming improved testing (or anything non-trivial) to Gitea is pointless, they're not open to collaboration. Upstreaming would also mean assigning copyright to Gitea, which is another thing *I* am not willing to do. I'd rather turn it around at this point: Gitea is free to cherry pick improvements and features from Forgejo (as long as they respect the relevant copyrights). Doing so would go a long way of showing they're open to collaboration. > @algernon While it won't be immediate, in the year or two following a hard fork it seems inevitable that Forgejo will diverge enough for it to be more and more difficult to benefit from new Gitea features/fixes, especially if one of the benefits of a hard fork is the ability to make architectural changes. Yes, indeed. A year or two is hopefully enough time for people to evaluate whether they want to go with Forgejo or Gitea. It's also short enough that if things go sideways, Forgejo can work on converging back into a soft-fork. > Release branches are maintained for a shorter time period, so it is understandable they wouldn't run into that problem quickly. In case of a hard fork, it seems likely that Forgejo will cease to function as "everything Gitea offers, with more features/fixes", with little upside for me as a user. That's a possibility. It will be its own entity, and people can choose based on what they need. If two projects have different priorities, allowing them to diverge is the logical path. I mean, Gitea itself is a fork of Gogs, which is still maintained and developed. Did hard-forking Gitea from Gogs hurt Gitea in the long run? I don't think so. Forgejo hard-forking from Gitea might lead to a similar outcome. But we won't know until we go there. On topic of difficulty: while diverging code bases will lead to patches not applying cleanly, the *ideas* will more than likely will apply for a much longer time. If Gitea has a bugfix, if it has tests, we can run a similar test against Forgejo, and see if the bug is present. Same for features. While we may not be able to cherry pick commits as-is, we can look at the code, and port it over.

earl-warren commented 2024年01月20日 23:48:28 +01:00

@gwymor to better understand your point of view, would you be willing to explain if you are running your own instance? Or if you are a user of an instance maintained by someone else? Your experience with regressions and half baked features will be different.

I share @algernon analysis and have dozens of pull requests sent to Gitea to show for it. There is one category of pull requests that are still successful: trivial bug fixes. Even security fixes ready-to-merge and tested were rejected at the expense of exposing Gitea admins to vulnerabilities during an extended period of time. No Gitea maintainer ever proposed a pull request to Forgejo. After over a year of efforts, it is safe to conclude there is no path to cooperation and that significant efforts were made Forgejo side. Larger changes such as improving the test infrastructure or the requirements for merging a pull request have always been out of reach.

@gwymor to better understand your point of view, would you be willing to explain if you are running your own instance? Or if you are a user of an instance maintained by someone else? Your experience with regressions and half baked features will be different. I share @algernon analysis and have dozens of pull requests sent to Gitea to show for it. There is one category of pull requests that are still successful: trivial bug fixes. Even security fixes ready-to-merge and tested were rejected at the expense of exposing Gitea admins to vulnerabilities during an extended period of time. No Gitea maintainer ever proposed a pull request to Forgejo. After over a year of efforts, it is safe to conclude there is no path to cooperation and that significant efforts were made Forgejo side. Larger changes such as improving the test infrastructure or the requirements for merging a pull request have always been out of reach.

CanisHelix commented 2024年01月21日 02:58:04 +01:00

I recently switched my self-hosted Gitea instance over to Forgejo due to it being a drop-in replacement. My main reasons were the idea of federation in the future, and not being open-core (I ditched Gitlab prior because they kept putting more features behind a paywall), and Gitea/Forgejo exposing the same API endpoints.

My main concern with a hard fork is that if and/or when the Forgejo API endpoints deviate from Gitea's.

I contribute to shields.io to implement 'badges' for Gitea/Forgejo as they share the same API currently, maintaining 2 integrations should they deviate just becomes hard. Other projects such as renovate also support Gitea and Forgejo currently would also be affected.

It's hard enough to find projects that integrate with Gitea already (most only support github/gitlab etc), but should the Forgejo API ever deviate from Gitea's, I fear that 3rd Party support for Forgejo would shrink. This is only an assumption as I have no idea what the install base is for Forgejo compared to Gitea, I only found Forgejo through their own Discord server and talks of Federation.

I recently switched my self-hosted Gitea instance over to Forgejo due to it being a drop-in replacement. My main reasons were the idea of federation in the future, and not being open-core (I ditched Gitlab prior because they kept putting more features behind a paywall), and Gitea/Forgejo exposing the same API endpoints. My main concern with a hard fork is that if and/or when the Forgejo API endpoints deviate from Gitea's. I contribute to [shields.io](https://shields.io) to implement 'badges' for Gitea/Forgejo as they share the same API currently, maintaining 2 integrations should they deviate just becomes hard. Other projects such as [renovate](https://www.npmjs.com/package/renovate) also support Gitea and Forgejo currently would also be affected. It's hard enough to find projects that integrate with Gitea already (most only support github/gitlab etc), but should the Forgejo API ever deviate from Gitea's, I fear that 3rd Party support for Forgejo would shrink. This is only an assumption as I have no idea what the install base is for Forgejo compared to Gitea, I only found Forgejo through their own Discord server and talks of Federation.

algernon commented 2024年01月21日 10:17:11 +01:00

Diverging code does not necessarily mean diverging APIs. There are plenty of examples out there where projects maintained an API for a long time, while the internals are nothing like they were 10 years before.

If maintaining a public facing API has clear benefits, like having existing integrations continuing to work smoothly, then that's a good goal to have. It does not require the internals to maintain compatibility, though. Like parts of the public Forgejo/Gitea API date back to Gogs, because there was no good reason to change it - at least at a cursory glance, there's quite a bit of overlap -, even though Gitea forked off of Gogs a long time ago.

Diverging code does not necessarily mean diverging APIs. There are plenty of examples out there where projects maintained an API for a *long* time, while the internals are nothing like they were 10 years before. If maintaining a public facing API has clear benefits, like having existing integrations continuing to work smoothly, then that's a good goal to have. It does not require the internals to maintain compatibility, though. Like parts of the public Forgejo/Gitea API date back to Gogs, because there was no good reason to change it - at least at a cursory glance, there's quite a bit of overlap -, even though Gitea forked off of Gogs a long time ago.

earl-warren commented 2024年01月21日 13:51:27 +01:00

The compatibility with the Gitea API to ensure interoperability with the Gitea ecosystem should be a commitment of the Forgejo hard fork, it is an important aspect that was overlooked. I have updated the description accordingly. @CanisHelix does that address your concern?

The compatibility with the Gitea API to ensure interoperability with the Gitea ecosystem should be a commitment of the Forgejo hard fork, it is an important aspect that was overlooked. I have updated the description accordingly. @CanisHelix does that address your concern?

earl-warren commented 2024年01月21日 13:58:44 +01:00

The following was added to ensure interoperability with the GItea ecosystem. @algernon @Gusted since you would be impacted by this, do you think it is reasonable?

Interoperability

To ensure interoperability with the existing Gitea ecosystem, the Forgejo API after a hard fork is updated to be compatible with the Gitea API.

The following was added to ensure interoperability with the GItea ecosystem. @algernon @Gusted since you would be impacted by this, do you think it is reasonable? ## Interoperability To ensure interoperability with the existing Gitea ecosystem, the Forgejo API after a hard fork is updated to be compatible with the Gitea API.

algernon commented 2024年01月21日 15:30:38 +01:00

I'd weaken the commitment a little, to allow Forgejo to deviate if there's a very good reason to do so, or to opt to not pick up new/changed API endpoints from Gitea. A strong commitment would require Forgejo to implement everything Gitea comes up with, regardless if that's useful for Forgejo or not. Such a hard commitment would also cause issues if Forgejo implements an API first, and Gitea implements something incompatible at the same endpoint later.

So I'd reword it a bit:

The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. Existing APIs at the time of the fork are public, and changing them is a breaking change, which has to be evaluated very carefully, and not done lightly. Future APIs should similarly be evaluated, and Forgejo will try to remain compatible with Gitea. However, Forgejo shall also use their own judgement whether to implement an API or not, and how - with the previous goals in mind.

This ended up being a bit more lawyerish than I intended, sorry. But I hope you get the idea about what I wanted to express O:)

I'd weaken the commitment a little, to allow Forgejo to deviate if there's a very good reason to do so, or to opt to not pick up new/changed API endpoints from Gitea. A strong commitment would require Forgejo to implement everything Gitea comes up with, regardless if that's useful for Forgejo or not. Such a hard commitment would also cause issues if Forgejo implements an API first, and Gitea implements something incompatible at the same endpoint later. So I'd reword it a bit: ``` The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. Existing APIs at the time of the fork are public, and changing them is a breaking change, which has to be evaluated very carefully, and not done lightly. Future APIs should similarly be evaluated, and Forgejo will try to remain compatible with Gitea. However, Forgejo shall also use their own judgement whether to implement an API or not, and how - with the previous goals in mind. ``` This ended up being a bit more lawyerish than I intended, sorry. But I hope you get the idea about what I wanted to express O:)

earl-warren commented 2024年01月21日 16:15:00 +01:00

I re-used your wording which is more explicit. It is common sense (rather than lawerish) in my view and better written down than implicit.

I re-used your wording which is more explicit. It is common sense (rather than lawerish) in my view and better written down than implicit.

earl-warren commented 2024年01月21日 16:16:46 +01:00

@CanisHelix FYI the commitment regarding interoperability with the Gitea ecosystem is now worded as follows:

The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. Existing APIs at the time of the fork are public, and changing them is a breaking change, which has to be evaluated very carefully, and not done lightly. Future APIs should similarly be evaluated, and Forgejo will try to remain compatible with Gitea. However, Forgejo shall also use their own judgement whether to implement an API or not, and how - with the previous goals in mind.

Does that address your concern?

@CanisHelix FYI the commitment regarding interoperability with the Gitea ecosystem is now worded as follows: > The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. Existing APIs at the time of the fork are public, and changing them is a breaking change, which has to be evaluated very carefully, and not done lightly. Future APIs should similarly be evaluated, and Forgejo will try to remain compatible with Gitea. However, Forgejo shall also use their own judgement whether to implement an API or not, and how - with the previous goals in mind. Does that address your concern?

earl-warren commented 2024年01月21日 16:19:23 +01:00

@algernon @Gusted the three of us are currently the only people who are going to be impacted by this commitment, for everyone else (casual contributors, Forgejo admins and users), it is an improvement over the previous proposal. For that reason I think not necessary to explicitly ask the people who approved the previous agreement proposal to review it again. Please let me know if you think differently.

@algernon @Gusted the three of us are currently the only people who are going to be impacted by this commitment, for everyone else (casual contributors, Forgejo admins and users), it is an improvement over the previous proposal. For that reason I think not necessary to explicitly ask the people who approved the previous agreement proposal to review it again. Please let me know if you think differently.

Gusted commented 2024年01月21日 18:27:30 +01:00

In the last year we've only diverged on API to make it more correct-ish, which is still compatible with the Gitea API as far as I'm concerned. So it's fine to include that, as it would not impact such development, but still restrict us going crazy with the API behavior.

In the last year we've only diverged on API to make it more correct-ish, which is still compatible with the Gitea API as far as I'm concerned. So it's fine to include that, as it would not impact such development, but still restrict us going crazy with the API behavior.

CanisHelix commented 2024年01月22日 04:26:04 +01:00

@earl-warren Thank you for the consideration and the new wording addresses my concerns very clearly with regards to trying to maintain interoperability with the gitea ecosystem.

@earl-warren Thank you for the consideration and the new wording addresses my concerns very clearly with regards to trying to maintain interoperability with the gitea ecosystem.

oliverpool commented 2024年01月25日 16:06:36 +01:00

To add some personal experience contributing to forgejo, I find the current workflow (regular rebase) to be quite challenging:

• one has to find the right branch to contribute to (sometime they conflict: changing a feature which contains some branding for instance forgejo/forgejo#2231)
• the pull-request links are currently lost upon rebase (I used git blame to find forgejo/forgejo@01191dc2ad, which does not mention forgejo/forgejo#1528, which got initially merged as forgejo/forgejo@901128221c - maybe this is a fixable issue of the rebase)

So I would very welcome a cherry-pick-based workflow!

---

What I miss from in initial post is a timeline/list of steps. On top of my head:

1. update the website regarding the possibility of becoming a "hard-fork", like https://forgejo.org/compare/#will-forgejo-become-a-hard-fork-of-gitea
2. publish a blog post informing of the intention of switching from "regular rebase" to "regular cherry-picking" starting with a given version of gitea. Telling that efforts are going to be made to ensure interoperability/compatibility.
3. add some automation to track the new commits of gitea, not considered in forgejo (it was suggested to open one PR per commit in #58 (comment) , this is probably too much noise - maybe one self-updating issue with checkboxes of some kind? Or a dedicated repo with one PR per merged PR of gitea?)
4. perform the switch in the workflow and update the developer documentation.

To add some personal experience contributing to forgejo, I find the current workflow (regular rebase) to be quite challenging: - one has to find the right branch to contribute to (sometime they conflict: changing a feature which contains some branding for instance forgejo/forgejo#2231) - the pull-request links are currently lost upon rebase (I used git blame to find https://codeberg.org/forgejo/forgejo/commit/01191dc2adf8c57ae448be37e73158005a8ff74d, which does not mention forgejo/forgejo#1528, which got initially merged as https://codeberg.org/forgejo/forgejo/commit/901128221c0c9d87c9377ee27b186565870a0430 - maybe this is a fixable issue of the rebase) So I would very welcome a cherry-pick-based workflow! --- What I miss from in initial post is a timeline/list of steps. On top of my head: 1. update the website regarding the possibility of becoming a "hard-fork", like https://forgejo.org/compare/#will-forgejo-become-a-hard-fork-of-gitea 2. publish a blog post informing of the intention of switching from "regular rebase" to "regular cherry-picking" starting with a given version of gitea. Telling that efforts are going to be made to ensure interoperability/compatibility. 3. add some automation to track the new commits of gitea, not considered in forgejo (it was suggested to open one PR per commit in https://codeberg.org/forgejo/governance/issues/58#issuecomment-1509539 , this is probably too much noise - maybe one self-updating issue with checkboxes of some kind? Or a dedicated repo with one PR per merged PR of gitea?) 4. perform the switch in the workflow and update the developer documentation.

earl-warren commented 2024年01月25日 17:09:21 +01:00

What I miss from in initial post is a timeline/list of steps. On top of my head:

• update the website regarding the possibility of becoming a "hard-fork", like https://forgejo.org/compare/#will-forgejo-become-a-hard-fork-of-gitea

That would be useful 👍

• publish a blog post informing of the intention of switching from "regular rebase" to "regular cherry-picking" starting with a given version of gitea. Telling that efforts are going to be made to ensure interoperability/compatibility.
• perform the switch in the workflow and update the developer documentation.

I believe this is covered by the How part of the agreement description. Maybe the part should be renamed Implementation details / How to be clearer?

• add some automation to track the new commits of gitea, not considered in forgejo (it was suggested to open one PR per commit in #58 (comment) , this is probably too much noise - maybe one self-updating issue with checkboxes of some kind? Or a dedicated repo with one PR per merged PR of gitea?)

I like the idea but I think it is going into too much detail in the context of this agreement. It would be a "nice to have" tool. I'm however not opposed to having it listed, if you have a different opinion.

> What I miss from in initial post is a timeline/list of steps. On top of my head: > > * update the website regarding the possibility of becoming a "hard-fork", like https://forgejo.org/compare/#will-forgejo-become-a-hard-fork-of-gitea That would be useful 👍 > * publish a blog post informing of the intention of switching from "regular rebase" to "regular cherry-picking" starting with a given version of gitea. Telling that efforts are going to be made to ensure interoperability/compatibility. > * perform the switch in the workflow and update the developer documentation. I believe this is covered by the **How** part of the agreement description. Maybe the part should be renamed **Implementation details / How** to be clearer? > * add some automation to track the new commits of gitea, not considered in forgejo (it was suggested to open one PR per commit in #58 (comment) , this is probably too much noise - maybe one self-updating issue with checkboxes of some kind? Or a dedicated repo with one PR per merged PR of gitea?) I like the idea but I think it is going into too much detail in the context of this agreement. It would be a "nice to have" tool. I'm however not opposed to having it listed, if you have a different opinion.

oliverpool commented 2024年01月26日 10:52:49 +01:00

I believe this is covered by the How part of the agreement description.

Yes, you are right.

It would be a "nice to have" tool.

I think it is worthwhile that the explicit interoperability goal has some actionable part (since this concern has been raised multiple times). I started a discussion to gather feedback over such a tool/procedure in a dedicated issue: forgejo/discussions#108

I hence propose to update the How section of the agreement to the following:

How

1. Update the website regarding the possibility of becoming a "hard-fork", like https://forgejo.org/compare/#will-forgejo-become-a-hard-fork-of-gitea (as soon as this agreement is accepted)
2. Perform the next major release (likely v1.22)
3. All feature branches are merged into the forgejo branch one last time
4. The developer workflow is updated to remove the part on feature branches
5. A blog post is published to announce the workflow change (and that Forgejo will try to stay a drop-in replacement of the self-hosted Gitea), the https://forgejo.org/compare/#will-forgejo-become-a-hard-fork-of-gitea is updated
6. Translations switch to using translate.codeberg.org
7. Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (to ensure compatibility / feature-parity): forgejo/discussions#108

> I believe this is covered by the How part of the agreement description. Yes, you are right. > It would be a "nice to have" tool. I think it is worthwhile that the explicit interoperability goal has some actionable part (since this concern has been raised multiple times). I started a discussion to gather feedback over such a tool/procedure in a dedicated issue: forgejo/discussions#108 I hence propose to update the `How` section of the agreement to the following: ## How 1. Update the website regarding the possibility of becoming a "hard-fork", like https://forgejo.org/compare/#will-forgejo-become-a-hard-fork-of-gitea (as soon as this agreement is accepted) 2. Perform the next major release (likely v1.22) 3. All [feature branches](https://forgejo.org/docs/v1.21/developer/workflow/#feature-branches) are merged into the forgejo branch one last time 4. The [developer workflow](https://forgejo.org/docs/v1.21/developer/workflow/) is updated to remove the part on feature branches 5. A blog post is published to announce the workflow change (and that Forgejo will try to stay a drop-in replacement of the self-hosted Gitea), the https://forgejo.org/compare/#will-forgejo-become-a-hard-fork-of-gitea is updated 6. Translations [switch to using translate.codeberg.org](https://codeberg.org/forgejo/discussions/issues/104) 7. Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (to ensure compatibility / feature-parity): forgejo/discussions#108

earl-warren commented 2024年01月26日 13:22:30 +01:00

Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (to ensure compatibility / feature-parity): forgejo/discussions#108

I agree with this addition. I think it is a natural extension of the commitment to ensure interoperability but it is best to make it explicit rather than implicit. There is no need to be specific about the tools or procedures in this agreement as they can be discussed later. They are an implementation detail.

@Gusted @algernon since you are the other two person who would be directly impacted please 👍 if you are ok with this addition and I'll update the topic accordingly. If you have suggestions on a better wording or concerns about the additional workload, please comment.

> Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (to ensure compatibility / feature-parity): forgejo/discussions#108 I agree with this addition. I think it is a natural extension of the commitment to ensure interoperability but it is best to make it explicit rather than implicit. There is no need to be specific about the tools or procedures in this agreement as they can be discussed later. They are an implementation detail. @Gusted @algernon since you are the other two person who would be directly impacted please 👍 if you are ok with this addition and I'll update the topic accordingly. If you have suggestions on a better wording or concerns about the additional workload, please comment.

Gusted commented 2024年01月26日 22:19:53 +01:00

I'm not sure if I understand, the first part sounds good to track what Gitea is doing, but I'm not sure if I understand the second part that we will ensure feature-parity. So we could choose for Gitea's implementation of a feature or our own, but either way one needs to be chosen and implemented?

I'm not sure if I understand, the first part sounds good to track what Gitea is doing, but I'm not sure if I understand the second part that we will ensure feature-parity. So we could choose for Gitea's implementation of a feature or our own, but either way one needs to be chosen and implemented?

earl-warren commented 2024年01月26日 22:24:18 +01:00

Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (to ensure compatibility / feature-parity): forgejo/discussions#108

This could be worded a little differently because I understand the part in parenthesis to be an example of what those tools are for rather than a commitment to ensure compatibility, which would be an impossible task.

Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (for instance when it is decided to implement compatibility / feature-parity in Forgejo)

@oliverpool @algernon is this also how you understand it?

> Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (to ensure compatibility / feature-parity): forgejo/discussions#108 This could be worded a little differently because I understand the part in parenthesis to be an example of what those tools are for rather than a commitment to ensure compatibility, which would be an impossible task. > Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (for instance when it is decided to implement compatibility / feature-parity in Forgejo) @oliverpool @algernon is this also how you understand it?

oliverpool commented 2024年01月26日 22:56:38 +01:00

Actually you can drop feature-parity and only keep compatibility/Interoperability, because this is what really matters (and was agreed upon).

Adding feature-parity was a mistake on my side (it is nice if it happens, but does not need an agreement I think).

Actually you can drop feature-parity and only keep compatibility/Interoperability, because this is what really matters (and was agreed upon). Adding feature-parity was a mistake on my side (it is nice if it happens, but does not need an agreement I think).

earl-warren commented 2024年01月26日 23:23:24 +01:00

@oliverpool I added the following as I believe it reflects what @Gusted @algernon and myself agree on. I did not replace the wording of the other points in the "How" section with yours but I think the meaning is equivalent.

Please let me know if I overlooked anything.

P.S. @algernon I did not wait for you to agree on the latest because it is less of a commitment than what you agreed on before. But don't hesitate to say if I missed something.
P.P.S although the discussion focused on getting an immediate consensus from the Forgejo contributors who are most impacted by the changes, it does not mean that other contributors can't weigh in. The important part of any commitment is to first make sure there are enough people willing to work to make it happen. Otherwise it would be an empty promise that noone is likely to fulfill.

---

Update 26 January 2024

The following is added

How

• Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (for instance when it is decided to implement compatibility / interoperability in Forgejo)

@oliverpool I added the following as I believe it reflects what @Gusted @algernon and myself agree on. I did not replace the wording of the other points in the "How" section with yours but I think the meaning is equivalent. Please let me know if I overlooked anything. P.S. @algernon I did not wait for you to agree on the latest because it is less of a commitment than what you agreed on before. But don't hesitate to say if I missed something. P.P.S although the discussion focused on getting an immediate consensus from the Forgejo contributors who are most impacted by the changes, it does not mean that other contributors can't weigh in. The important part of any commitment is to first make sure there are enough people willing to work to make it happen. Otherwise it would be an empty promise that noone is likely to fulfill. --- Update 26 January 2024 The following is added ## How * Tools and/or procedures are written to allow Forgejo to track the commits of Gitea (for instance when it is decided to implement compatibility / interoperability in Forgejo)

earl-warren commented 2024年01月28日 14:39:09 +01:00

As of today Forgejo translations are hosted on Weblate and it is no longer a blocker for a hard fork. The following item:

How

• Translations switch to using translate.codeberg.org

Was removed.

As of today Forgejo translations are hosted on Weblate and it is no longer a blocker for a hard fork. The following item: > ## How > > * Translations [switch to using translate.codeberg.org](https://codeberg.org/forgejo/discussions/issues/104) Was removed.

earl-warren commented 2024年01月28日 14:42:38 +01:00

@gwymor to better understand your point of view, would you be willing to explain if you are running your own instance? Or if you are a user of an instance maintained by someone else? Your experience with regressions and half baked features will be different.

Gentle ping.

> @gwymor to better understand your point of view, would you be willing to explain if you are running your own instance? Or if you are a user of an instance maintained by someone else? Your experience with regressions and half baked features will be different. Gentle ping.

gwymor commented 2024年01月28日 22:48:47 +01:00

@earl-warren What you and @algernon wrote above about collaboration with Gitea is quite unfortunate. Given that, it seems there's not much you can do at this point but diverge. I can't say I like/want that outcome, but it seems you are figuring out how to do it in the best way you can for users (forgejo/discussions#108). Best of luck to you and I hope if I or others contribute to Gitea in the future, the contributions remain useful to the Forgejo project without too much effort on your part.

Aside, people have mentioned the difficulty of there being multiple branches different parts of Forgejo use. What is the benefit of keeping different types of changes in different branches? If Forgejo doesn't switch (or before it switches) to cherry-picking from Gitea, would having only a single branch that is rebased on Gitea be easier for contributors and the maintainers?

@earl-warren What you and @algernon wrote above about collaboration with Gitea is quite unfortunate. Given that, it seems there's not much you can do at this point but diverge. I can't say I like/want that outcome, but it seems you are figuring out how to do it in the best way you can for users (forgejo/discussions#108). Best of luck to you and I hope if I or others contribute to Gitea in the future, the contributions remain useful to the Forgejo project without too much effort on your part. Aside, people have mentioned the difficulty of there being multiple branches different parts of Forgejo use. What is the benefit of keeping different types of changes in different branches? If Forgejo doesn't switch (or before it switches) to cherry-picking from Gitea, would having only a single branch that is rebased on Gitea be easier for contributors and the maintainers?

eNBeWe commented 2024年01月29日 10:35:38 +01:00

Personally, I think it is time for the hard fork.
My only concern is the issue of migration paths.
I run my own Forgejo server for personal projects and I also run a Gitea instance for my work.
I would like to be able to just switch the Gitea over to Forgejo right now, but I don't think there is a good way for that (mainly due to reservations/concerns of superiors). The option of the drop-in replacement keeps the migration path very wide open for me and I can have a look at how the projects evolve. If/when I find a compelling argument to make the switch I can propose it and then hopefully do the switch.
BUT: When we loose the "drop-in migration" at some point, we are still able to do the full migration through "conventional" means, using the migrations/mirrors one repo at a time. Would it be feasible to supply some kind of migration tool when we reach this point?

Personally, I think it is time for the hard fork. My only concern is the issue of migration paths. I run my own Forgejo server for personal projects and I also run a Gitea instance for my work. I would like to be able to just switch the Gitea over to Forgejo right now, but I don't think there is a good way for that (mainly due to reservations/concerns of superiors). The option of the drop-in replacement keeps the migration path very wide open for me and I can have a look at how the projects evolve. If/when I find a compelling argument to make the switch I can propose it and then hopefully do the switch. BUT: When we loose the "drop-in migration" at some point, we are still able to do the full migration through "conventional" means, using the migrations/mirrors one repo at a time. Would it be feasible to supply some kind of migration tool when we reach this point?

earl-warren commented 2024年01月29日 10:58:27 +01:00

Would it be feasible to supply some kind of migration tool when we reach this point?

Yes, that's my main focus on Forgejo, with F3 which is exactly that. Not just for Gitea but for all other forges as well. A building block of federation as well. It will go like this:

• Today: Forgejo is a drop in replacement for Gitea
• Transition: ad-hoc tooling is needed to convert a Gitea dump and restore it as a Forgejo instance
• Maturity: Gitea is exported as a F3 dump and can be restored in Forgejo

The unknown is the transition phase. F3 is taking a long time to mature. But I am committed to make it work because it is necessary for federation.

In conclusion my answer to your concern is that there will be a "Transition" period when it becomes harder to migrate from Gitea to Forgejo. Until it becomes seamless again because federation reaches maturity and provides all the tools you would need.

> Would it be feasible to supply some kind of migration tool when we reach this point? Yes, that's my main focus on Forgejo, with [F3](https://f3.forgefriends.org/) which is exactly that. Not just for Gitea but for all other forges as well. A building block of federation as well. It will go like this: * Today: Forgejo is a drop in replacement for Gitea * Transition: ad-hoc tooling is needed to convert a Gitea dump and restore it as a Forgejo instance * Maturity: Gitea is exported as a F3 dump and can be restored in Forgejo The unknown is the transition phase. F3 is taking a long time to mature. **But I am committed to make it work because it is necessary for federation.** In conclusion my answer to your concern is that there will be a "Transition" period when it becomes harder to migrate from Gitea to Forgejo. Until it becomes seamless again because federation reaches maturity and provides all the tools you would need.

mbateman commented 2024年01月31日 01:44:12 +01:00

It's fascinating that the stated reason for the gitea hard fork is rooted in disagreements over governance, given that forgejo itself emerged from similar concerns. While I understand the frustration on both sides, the current discourse filled with accusations of hostility seems unproductive and detrimental to the community. Instead of perpetuating this negativity, I urge both gitea and forgejo to focus on their respective strengths and find a way to coexist and collaborate for the benefit of all users.

It's fascinating that the stated reason for the gitea hard fork is rooted in disagreements over governance, given that forgejo itself emerged from similar concerns. While I understand the frustration on both sides, the current discourse filled with accusations of hostility seems unproductive and detrimental to the community. Instead of perpetuating this negativity, I urge both gitea and forgejo to focus on their respective strengths and find a way to coexist and collaborate for the benefit of all users.

Ghost commented 2024年01月31日 08:49:03 +01:00

@mbateman I agree for the most part with what you wrote. It is a conversation that should happen in the comparison page pull request.

It's fascinating that the stated reason for the gitea hard fork is rooted in disagreements over governance...

The primary benefit is of technical nature, to more effectively contain regressions as written above:

• It allows to not be impacted by regressions introduced in Gitea (see the blog post about the storage regressions, the pull request that refactored the PAT in v1.20 which had unspecified side effects and led to the recommendation to re-create all tokens and the pull request that implements actions which is still mostly untested today)

@mbateman I agree for the most part with what you wrote. It is a conversation that should happen in the [comparison page](https://codeberg.org/forgejo/website/pulls/406) pull request. > It's fascinating that the stated reason for the gitea hard fork is rooted in disagreements over governance... The primary benefit is of technical nature, to [more effectively contain regressions](https://codeberg.org/forgejo/discussions/issues/103) as written above: > * It **allows to not be impacted by regressions introduced in Gitea** (see [the blog post about the storage regressions](https://forgejo.org/2023-09-monthly-update/#fixing-s3-configuration-bugs-and-regressions), the [pull request that refactored the PAT in v1.20](https://github.com/go-gitea/gitea/pull/24767) which had unspecified side effects and led to the recommendation to re-create all tokens and [the pull request that implements actions](https://github.com/go-gitea/gitea/pull/21937/files) which is still mostly untested today)

CactiChameleon9 commented 2024年02月03日 11:34:37 +01:00

Only the most trivial bug fixes originating from Forgejo have been successfully contributed to Gitea, features or even security fixes are either stalled, re-written or rejected.

This feels like an exaggeration, is there something specific here that points to there being a major problem? Most of the closed PRs I looked at seemed to have sensible enough reasons?

https://github.com/go-gitea/gitea/pulls?q=is%3Apr+forgejo%2Fpulls+is%3Aunmerged

> Only the most trivial bug fixes originating from Forgejo have been successfully contributed to Gitea, features or even security fixes are either stalled, re-written or rejected. This feels like an exaggeration, is there something specific here that points to there being a major problem? Most of the closed PRs I looked at seemed to have sensible enough reasons? https://github.com/go-gitea/gitea/pulls?q=is%3Apr+forgejo%2Fpulls+is%3Aunmerged

earl-warren commented 2024年02月03日 13:15:11 +01:00

This feels like an exaggeration, is there something specific here that points to there being a major problem?

The following two PRs are security fixes ready to merge: they were closed and re-implemented for no reason, leaving Gitea admins exposed to security risks for an extended period of time.

• rework long-term authentication
• Fail when API & web endpoints use unrelated ids

There is a larger discussions which is worth having on how to evaluate the cooperation between Forgejo and Gitea in 2023 and a discussion was opened for that purpose.

> This feels like an exaggeration, is there something specific here that points to there being a major problem? The following two PRs are security fixes ready to merge: they were closed and re-implemented for no reason, leaving Gitea admins exposed to security risks for an extended period of time. * [rework long-term authentication](https://github.com/go-gitea/gitea/pull/27455) * [Fail when API & web endpoints use unrelated ids](https://github.com/go-gitea/gitea/pull/28211) There is a larger discussions which is worth having on how to evaluate the cooperation between Forgejo and Gitea in 2023 and [a discussion was opened](https://codeberg.org/forgejo/discussions/issues/111) for that purpose.

forgejo-moderation commented 2024年02月03日 14:09:16 +01:00

A message from an account created to circumvent a ban from Forgejo spaces was deleted, send a mail to moderation@forgejo.org for more information.

A message from an account created to circumvent a ban from Forgejo spaces was deleted, send a mail to moderation@forgejo.org for more information.

KN4CK3R commented 2024年02月03日 15:21:35 +01:00

Sad to see, that reasonable comments get deleted.

Sad to see, that reasonable comments get deleted.

earl-warren commented 2024年02月03日 15:29:44 +01:00

@KN4CK3R the moderation policy of Forgejo is off-topic here. Please open a discussion or write to moderation@forgejo.org.

@KN4CK3R the moderation policy of Forgejo is off-topic here. Please [open a discussion](https://codeberg.org/forgejo/discussions/issues) or write to moderation@forgejo.org.

crystal commented 2024年02月03日 16:44:48 +01:00

Comments like this are not reasonable or helpful. Forgejo contributors do not enter Gitea spaces and say things just to cause strife, I'd appreciate it if you'd extend the same respect to us.

Comments [like this](https://codeberg.org/forgejo/governance/issues/58#issuecomment-1547824) are not reasonable or helpful. Forgejo contributors do not enter Gitea spaces and say things just to cause strife, I'd appreciate it if you'd extend the same respect to us.

KN4CK3R commented 2024年02月03日 16:46:01 +01:00

It's not about my comment but about what is deleted now.

It's not about my comment but about what is deleted now.

crystal commented 2024年02月03日 16:54:23 +01:00

That much is clear, but I was referring to your comment. I do not believe that it contributes anything meaningful or productive to this conversation, instead serving only as a vague derogatory implication about Forgejo's moderation policies.

That much is clear, but I was referring to your comment. I do not believe that it contributes anything meaningful or productive to this conversation, instead serving only as a vague derogatory implication about Forgejo's moderation policies.

KN4CK3R commented 2024年02月03日 18:01:02 +01:00

CactiChameleon9 asked a question, earl-warren answered with A, someone else answered with B. Then B gets deleted. I posted in the correct topic.

CactiChameleon9 asked a question, earl-warren answered with A, someone else answered with B. Then B gets deleted. I posted in the correct topic.

Cyborus commented 2024年02月03日 18:03:16 +01:00

The post was deleted because that person is banned from Forgejo spaces, not the content of their message. Please get back on topic.

The post was deleted because that person is banned from Forgejo spaces, not the content of their message. Please get back on topic.

mbateman commented 2024年02月04日 00:51:50 +01:00

@mbateman I agree for the most part with what you wrote. It is a conversation that should happen in the comparison page pull request.

It's fascinating that the stated reason for the gitea hard fork is rooted in disagreements over governance...

The primary benefit is of technical nature, to more effectively contain regressions as written above:

• It allows to not be impacted by regressions introduced in Gitea (see the blog post about the storage regressions, the pull request that refactored the PAT in v1.20 which had unspecified side effects and led to the recommendation to re-create all tokens and the pull request that implements actions which is still mostly untested today)

I would have thought the primary benefit is of a technical nature: to better handle development. It was always a surprise when forgejo was spawned it wasn't just a hard-fork as to not do so only brings additional overhead.

To allow to not be impacted by regressions... this is an odd one especially since no software project wants regressions and the only way to really limit this (limit not eradicate) is via requirements and tests. Now FOSS is guilty of not really capturing requirements and flowing down and reviewing against requirements and thus every single FOSS program is going to be exposed to a regression. Tests... yes test help but they are only as good as the tests that are written and they never provide total coverage. beta testing is the best way and this is what most do and every single foss program picks up issues during RC... like the most recent linux-6.8 NEXT having a major performance regression... people need to test and report back prior to a formal release. Thus regressions are something that must be prepared for. As a reason to hard fork though, this seems odd and over dramatised because I can guarantee you that forgejo will have their own regressions (plural). Likewise other FOSS projects have had more damning regressions (the zero data bug in OpenZFS) but you do not see a cabal considering a fork and this one is interesting as the specifications are managed via Oracle and filesystems are some of the most comprehensive code and tested code there is and yet a major regression still occurred.

Now security... this is always a key one, especially for web-based services. There has been some quite inflammatory statements from forgejo, in forgejo spaces directed at gitea along the lines that gitea do not take security seriously. Looking into the MR submitted into gitea, the ones that are used against gitea, it isn't as clear cut as it is made out to be (in this thread and others).
One that was closed and totally re-written had substantial growth and touched almost twice as many files. This would imply aspects of the MR were incomplete. Another had some heated discussions about the contribution headers and this was odd as the contribution header has apparently been a policy for many years. Also this isn't unique and the Gentoo project is a perfect example where the ebuilds are copyrighted as Gentoo but the Certificate of Origin is stored within the git structure. The final one was odd and whether there was a non-standard way or reporting or there was a breakdown in how gitea manages their security reports... who knows but that should have triggered a review to improve someones process as it clearly failed.

Now collaboration, this is the one I find really odd. A group of users decide they do not want to work with gitea (for a range of reasons) and create forgejo and then complain when gitea do not want to collaborate. Sorry but this isn't 18C France with Marie Antoinette.

Honestly... I think the entire decision to "fork" was way to hasty and while concerns existed about opencore, this itself isn't a problem but could be and only time will tell.. MantisBT is still happily being developed and only a thin shim exists for MantisHub. Likewise Freecad went opencore and so far Ondsel hasn't gone crazy with what is in the closed portion. That's not to say it couldn't and if/when they did move the contribution line too far I wouldn't be surprised if forks occured, but to date none have because it is working. So personally the argument (and how) forgejo was formed is already questionable but it is formed and thus a hard fork should have always been what occurred.

> @mbateman I agree for the most part with what you wrote. It is a conversation that should happen in the [comparison page](https://codeberg.org/forgejo/website/pulls/406) pull request. > > > It's fascinating that the stated reason for the gitea hard fork is rooted in disagreements over governance... > > The primary benefit is of technical nature, to [more effectively contain regressions](https://codeberg.org/forgejo/discussions/issues/103) as written above: > > > * It **allows to not be impacted by regressions introduced in Gitea** (see [the blog post about the storage regressions](https://forgejo.org/2023-09-monthly-update/#fixing-s3-configuration-bugs-and-regressions), the [pull request that refactored the PAT in v1.20](https://github.com/go-gitea/gitea/pull/24767) which had unspecified side effects and led to the recommendation to re-create all tokens and [the pull request that implements actions](https://github.com/go-gitea/gitea/pull/21937/files) which is still mostly untested today) > I would have thought the primary benefit is of a technical nature: to better handle development. It was always a surprise when forgejo was spawned it wasn't just a hard-fork as to not do so only brings additional overhead. To allow to not be impacted by regressions... this is an odd one especially since no software project wants regressions and the only way to really limit this (limit not eradicate) is via requirements and tests. Now FOSS is guilty of not really capturing requirements and flowing down and reviewing against requirements and thus every single FOSS program is going to be exposed to a regression. Tests... yes test help but they are only as good as the tests that are written and they never provide total coverage. beta testing is the best way and this is what most do and every single foss program picks up issues during RC... like the most recent linux-6.8 NEXT having a major performance regression... people need to test and report back prior to a formal release. Thus regressions are something that must be prepared for. As a reason to hard fork though, this seems odd and over dramatised because I can guarantee you that forgejo will have their own regressions (plural). Likewise other FOSS projects have had more damning regressions (the zero data bug in OpenZFS) but you do not see a cabal considering a fork and this one is interesting as the specifications are managed via Oracle and filesystems are some of the most comprehensive code and tested code there is and yet a major regression still occurred. Now security... this is always a key one, especially for web-based services. There has been some quite inflammatory statements from forgejo, in forgejo spaces directed at gitea along the lines that gitea do not take security seriously. Looking into the MR submitted into gitea, the ones that are used against gitea, it isn't as clear cut as it is made out to be (in this thread and others). One that was closed and totally re-written had substantial growth and touched almost twice as many files. This would imply aspects of the MR were incomplete. Another had some heated discussions about the contribution headers and this was odd as the contribution header has apparently been a policy for many years. Also this isn't unique and the Gentoo project is a perfect example where the ebuilds are copyrighted as Gentoo but the Certificate of Origin is stored within the git structure. The final one was odd and whether there was a non-standard way or reporting or there was a breakdown in how gitea manages their security reports... who knows but that should have triggered a review to improve someones process as it clearly failed. Now collaboration, this is the one I find really odd. A group of users decide they do not want to work with gitea (for a range of reasons) and create forgejo and then complain when gitea do not want to collaborate. Sorry but this isn't 18C France with Marie Antoinette. Honestly... I think the entire decision to "fork" was way to hasty and while concerns existed about opencore, this itself isn't a problem but could be and only time will tell.. MantisBT is still happily being developed and only a thin shim exists for MantisHub. Likewise Freecad went opencore and so far Ondsel hasn't gone crazy with what is in the closed portion. That's not to say it couldn't and if/when they did move the contribution line too far I wouldn't be surprised if forks occured, but to date none have because it is working. So personally the argument (and how) forgejo was formed is already questionable but it is formed and thus a hard fork should have always been what occurred.

earl-warren commented 2024年02月04日 01:44:15 +01:00

So personally the argument (and how) forgejo was formed is already questionable but it is formed and thus a hard fork should have always been what occurred.

I agree with your conclusion that Forgejo should be a hard fork.

If anyone would like to answer to @mbateman opinions on Forgejo, please do so in another discussion since they are not concerns that need to be addressed in order for the agreement to be concluded. It will greatly help keep this discussion focused. 🙏

> So personally the argument (and how) forgejo was formed is already questionable but it is formed and thus a hard fork should have always been what occurred. I agree with your conclusion that Forgejo should be a hard fork. If anyone would like to answer to @mbateman opinions on Forgejo, please do so in another discussion since they are not concerns that need to be addressed in order for the agreement to be concluded. It will greatly help keep this discussion focused. 🙏

Codeberg.org commented 2024年02月04日 08:35:47 +01:00

A message was redacted by the Codeberg moderation team for repeatedly posting the same message over and over again, circumventing a ban established by a project.

We want to remind everyone that nice behaviour in project is key to collaboration. Things that have been discussed once do not need to be spammed again and again. Thank you for your understanding.

Please contact the Forgejo moderation team, they have received a copy of the removed messages.

A message was redacted by the Codeberg moderation team for repeatedly posting the same message over and over again, circumventing a ban established by a project. We want to remind everyone that nice behaviour in project is key to collaboration. Things that have been discussed once do not need to be spammed again and again. Thank you for your understanding. Please contact the Forgejo moderation team, they have received a copy of the removed messages.

Codeberg.org commented 2024年02月04日 09:24:41 +01:00

We have removed another message due to violating our Terms of Use (repeated circumvent of a ban via multiple accounts). The Forgejo moderation team has received a copy. We belive that this governance issue is not made for discussing unrelated facts.

We have removed another message due to violating our Terms of Use (repeated circumvent of a ban via multiple accounts). The Forgejo moderation team has received a copy. We belive that this governance issue is not made for discussing unrelated facts.

earl-warren commented 2024年02月06日 00:19:26 +01:00

I believe the agreement is final and can be implemented. I asked if there was any objection in the development chatroom today but there were none.

If anyone disagrees, please comment here. Gentle reminder: this is not an open discussion, it is an agreement that follows the Forgejo decision making process. In a nutshell it means that the agreement is final when all concerns have been addressed and that all stakeholders have had an opportunity to see this discussion and think about the consequences. Given the volume of discussions and the number of participants, there is little doubt that it received an audience that is both large and diverse. There has been no new concern expressed since 29 January and they have all been addressed.

Concerns

• @eNBeWe concerns on the transition path were resolved
• @gwymor concerns on the loss of features were discussed but not resolved and they concluded with "@earl-warren What you and @algernon wrote above about collaboration with Gitea is quite unfortunate. Given that, it seems there's not much you can do at this point but diverge"
• @CanisHelix concern on Forgejo API endpoints deviating from Gitea's led to an additional commitment on interoperability that resolved the concern

Next steps

Since it is expected that no new concern will come to light, the "How" part of the agreement can begin immediately. The details and the timing are left at the discretion of the people willing to do the work, depending on their availability.

I believe the agreement is final and can be implemented. I asked if there was any objection [in the development chatroom today](https://matrix.to/#/!zpNKWqkiEOyljSMQDK:matrix.org/$eYb00L-jVtYLkQhqlByej9E42d1BVWJKxivxPxMRGoA?via=schinas.net&via=matrix.org&via=aria-net.org) but there were none. If anyone disagrees, please comment here. Gentle reminder: this is not an open discussion, it is an agreement that follows the [Forgejo decision making process](https://codeberg.org/forgejo/governance/src/branch/main/DECISION-MAKING.md). In a nutshell it means that the agreement is final when all concerns have been addressed and that all stakeholders have had an opportunity to see this discussion and think about the consequences. Given the volume of discussions and the number of participants, there is little doubt that it received an audience that is both large and diverse. There has been no new concern expressed since 29 January and they have all been addressed. ## Concerns - @eNBeWe concerns on the [transition path](https://codeberg.org/forgejo/governance/issues/58#issuecomment-1540464) were [resolved](https://codeberg.org/forgejo/governance/issues/58#issuecomment-1540492) - @gwymor concerns on [the loss of features](https://codeberg.org/forgejo/governance/issues/58#issuecomment-1502233) were discussed but not resolved and they [concluded](https://codeberg.org/forgejo/governance/issues/58#issuecomment-1539939) with "@earl-warren What you and @algernon wrote above about collaboration with Gitea is quite unfortunate. Given that, it seems there's not much you can do at this point but diverge" - @CanisHelix concern on [Forgejo API endpoints deviating from Gitea's](https://codeberg.org/forgejo/governance/issues/58#issuecomment-1523731) led to an [additional commitment on interoperability](https://codeberg.org/forgejo/governance/issues/58#issuecomment-1526303) that [resolved the concern](https://codeberg.org/forgejo/governance/issues/58#issuecomment-1528927) ## Next steps Since it is expected that no new concern will come to light, **the "How" part of the agreement can begin immediately**. The details and the timing are left at the discretion of the people willing to do the work, depending on their availability.

KaKi87 commented 2024年02月11日 20:59:30 +01:00

The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork.

What about SemVer ?

Is the hard fork going to facilitate transitioning in any way, or still leave it stalled ?

> The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. What about SemVer ? Is the hard fork going to facilitate transitioning in any way, or still leave it stalled ?

algernon commented 2024年02月11日 21:10:24 +01:00

The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork.

What about SemVer ?

Is the hard fork going to facilitate transitioning in any way, or still leave it stalled ?

forgejo/forgejo#2327

In my reading, this means /api/v1/version will remain a fixed Gitea version, /api/forgejo/v1/version, and the version showed otherwise will move to the Forgejo SemVer.

> > The Forgejo API will strive to remain compatible with the Gitea API going forward, after a hard fork. > > What about SemVer ? > > Is the hard fork going to facilitate transitioning in any way, or still leave it stalled ? https://codeberg.org/forgejo/forgejo/pulls/2327 In my reading, this means `/api/v1/version` will remain a fixed Gitea version, `/api/forgejo/v1/version`, and the version showed otherwise will move to the Forgejo SemVer.

KaKi87 commented 2024年02月12日 07:01:58 +01:00

I actually wasn't talking about the API but the rest of forgejo/forgejo#207.

Thanks

I actually wasn't talking about the API but the rest of forgejo/forgejo#207. Thanks

algernon commented 2024年02月12日 07:07:41 +01:00

I actually wasn't talking about the API but the rest of forgejo/forgejo#207.

Yes, and I believe forgejo/forgejo#2327 addresses that:

• The package version will bump from v1.21.x to v7.0.0

That version (v7.0.0) is what's used whenever referring to a Forgejo version, both in the API, and in other places where the version appears. /api/v1/version will remain a static Gitea version to be compatible with Gitea SDKs and clients and whatnot, but everything else can move to proper SemVer. The change in forgejo/forgejo#2327 should enable that process to move forward.

> I actually wasn't talking about the API but the rest of forgejo/forgejo#207. Yes, and I believe forgejo/forgejo#2327 addresses that: > - The package version will bump from v1.21.x to v7.0.0 That version (`v7.0.0`) is what's used whenever referring to a Forgejo version, both in the API, and in other places where the version appears. `/api/v1/version` *will* remain a static Gitea version to be compatible with Gitea SDKs and clients and whatnot, but everything else *can* move to proper SemVer. The change in forgejo/forgejo#2327 should enable that process to move forward.

earl-warren commented 2024年02月16日 00:06:49 +01:00

All items in the checklist of the implementation are either done (blog post, feature branches are no longer in use, the developer workflow documentation was updated) or bootstrapped: cherry-picking instead of rebasing is in its third iteration with procedures and tooling being discussed and experimented with.

This concludes the implementation of the decision itself, even if the work that began will continue for the foreseeable future.

All items in the checklist of the implementation are either done ([blog post](https://forgejo.org/2024-02-forking-forward/), feature branches are no longer in use, the developer workflow documentation was updated) or bootstrapped: cherry-picking instead of rebasing is in its third iteration with procedures and tooling being discussed and experimented with. This concludes the implementation of the decision itself, even if the work that began will continue for the foreseeable future.