forgejo/discussions
49
43

Proposal for a simpler development workflow / hard fork #96

Closed
opened 2024年01月06日 22:17:37 +01:00 by earl-warren · 36 comments

TL;DR: Use only one branch for Forgejo development and no longer rebase on top of Gitea. Use it as an inspiration instead, taking only the good parts.

The Forgejo development workflow could be simplified to be a single development branch instead of multiple feature branches. Instead of being rebased on top of Gitea, it would become independent and cherry-pick from the Gitea codebase until the divergences are too great and that becomes impossible.

It could be called a hard fork but it really is the last step in a process that is already well under way (if not done) for other parts in Forgejo: documentation, releases, runner, test suites... A rough estimate would be that Forgejo is now half hard forked from Gitea and that would complete the other half.

Six months ago it was sensible for Forgejo to evolve on top of Gitea but a lot has happened since and it shifted the balance:

  • Gitea merges very large untested code (feature or refactor) that have been the cause of major regressions with high impact on users (for the year 2023 alone see the blog post about the storage regressions for an example or the pull request that refactored the PAT in v1.20 which had such unspecified side effects that the only sound advice for security was to re-create all tokens and the pull request that introduced actions, a 7000+ lines PR with almost no test coverage).
  • Forgejo grew to have more contributors
  • Forgejo completed the groundwork required of a new software project (security, releases, infrastructure)
  • Gitea turned Open Core and will keep adding proprietary features
  • Gitea is engaged in shady security behavior

This simpler development workflow would have benefits:

  • more familiar to the contributors: a single development branch instead of multiple feature branches
  • simpler fixes & features implementation because they do not need to be concerned by future conflicts & refactors in Gitea
  • the weekly cleanup would be more about choosing the good parts to use from Gitea and other dependencies and less about conflict resolution
  • more stability as most changes merged in Forgejo are tested
  • improved documentation on existing features that are currently hidden

The downsides are that:

  • bug fixes found in Gitea will gradually become impossible to cherry-pick. They will have to be ported to Forgejo. The same goes for new features
  • Forgejo will no longer be a drop-in replacement for Gitea

What is your opinion as someone actively involved in the development of Forgejo? It would directly impact your work. Do you think the benefits are greater than the downsides? Do you think it is a good step to take to improve Forgejo growth? Do you have reservations?

TL;DR: Use only one branch for Forgejo development and no longer rebase on top of Gitea. Use it as an inspiration instead, taking only the good parts. The [Forgejo development workflow](https://forgejo.org/docs/v1.21/developer/workflow/) could be simplified to be a single development branch instead of multiple feature branches. Instead of being rebased on top of Gitea, it would become independent and cherry-pick from the Gitea codebase until the divergences are too great and that becomes impossible. It could be called a **hard fork** but it really is the last step in a process that is already well under way (if not done) for other parts in Forgejo: documentation, releases, runner, test suites... A rough estimate would be that Forgejo is now half hard forked from Gitea and that would complete the other half. Six months ago it was sensible for Forgejo to evolve on top of Gitea but a lot has happened since and it shifted the balance: * **Gitea merges very large untested code (feature or refactor) that have been the cause of major regressions with high impact on users** (for the year 2023 alone see [the blog post about the storage regressions](https://forgejo.org/2023-09-monthly-update/#fixing-s3-configuration-bugs-and-regressions) for an example or the [pull request that refactored the PAT in v1.20](https://github.com/go-gitea/gitea/pull/24767) which had such unspecified side effects that the only sound advice for security was to re-create all tokens and [the pull request that introduced actions](https://github.com/go-gitea/gitea/pull/21937/files), a 7000+ lines PR with almost no test coverage). * Forgejo grew to have more contributors * Forgejo completed the groundwork required of a new software project (security, releases, infrastructure) * Gitea turned Open Core and will keep adding proprietary features * Gitea is engaged in shady security behavior This simpler development workflow would have benefits: * more familiar to the contributors: a single development branch instead of multiple feature branches * simpler fixes & features implementation because they do not need to be concerned by future conflicts & refactors in Gitea * the weekly cleanup would be more about choosing the good parts to use from Gitea and other dependencies and less about conflict resolution * more stability as most changes merged in Forgejo are tested * improved documentation on existing features that are currently hidden The downsides are that: * bug fixes found in Gitea will gradually become impossible to cherry-pick. They will have to be ported to Forgejo. The same goes for new features * Forgejo will no longer be a drop-in replacement for Gitea **What is your opinion as someone actively involved in the development of Forgejo?** It would directly impact your work. Do you think the benefits are greater than the downsides? Do you think it is a good step to take to improve Forgejo growth? Do you have reservations?

My opinion as a Forgejo contributor is that it would be beneficial to implement such a simplified workflow within the next three months, provided:

  • it is advertised properly because it means Gitea users will no longer have a drop in replacement in Forgejo
  • an effort is made to document existing features (blog posts as well as documentation) on a regular basis (once a month). There are so many of them in Forgejo, it will be enough material for a few years. To most users (and people considering Forgejo), it will be like having a new feature every month. I've seen that with Forgejo Actions: every time a feature is documented it feels like it is new, just because I now understand how to use it and can rely on documentation to do so.

Other than this, I strongly believe it is the only way to put an end to the recurring regressions caused by untested changes. It is not rocket science too, but it makes all the difference in the world.

FWIW I plan to keep working on Forgejo in 2024 as I did in 2023, focusing on the F3 driver, releases, Forgejo Actions, infrastructure&CI, security, moderation (in that order).

My opinion as a Forgejo contributor is that it would be beneficial to implement such a simplified workflow within the next three months, provided: * it is advertised properly because it means Gitea users will no longer have a drop in replacement in Forgejo * an effort is made to document existing features (blog posts as well as documentation) on a regular basis (once a month). There are so many of them in Forgejo, it will be enough material for a few years. To most users (and people considering Forgejo), it will be like having a new feature every month. I've seen that with Forgejo Actions: every time a feature is documented it feels like it is new, just because I now understand how to use it and can rely on documentation to do so. Other than this, I strongly believe it is the only way to put an end to the recurring regressions caused by untested changes. It is not rocket science too, but it makes all the difference in the world. FWIW I plan to keep working on Forgejo in 2024 as I did in 2023, focusing on the F3 driver, releases, Forgejo Actions, infrastructure&CI, security, moderation (in that order).

I'm against a hard fork. I don't think it's a good idea to split the contributors into 2 projects. This will hurt more than it helps in the long term.

I'm against a hard fork. I don't think it's a good idea to split the contributors into 2 projects. This will hurt more than it helps in the long term.

I'm a long-time Forgejo user (switched pretty much with the first release), and recently a contributor too. I have... mixed feelings. On one hand, I believe that a hard fork is eventually inevitable. I also believe that it is a step that should be taken long before it becomes inevitable. I also agree that in the long run - and likely in the short run too - it would benefit Forgejo a lot, it would give Forgejo more freedom to do what developers feel necessary, it might feel like loosing a set of chains.

On the other hand, the question I keep asking myself is: is this the right time to make that step? Is three months enough? Perhaps a slower, more cautious plan might work better. One where the decision is not made "immediately" when a consensus is reached. Rather, it would be a bit of exploration at first: rather than a weekly rebase, do it every two weeks. Then start cherry picking inbetween rebases, and if all of those work out well, then stop rebasing. But even before that, get a release or two out, perhaps a couple of blog posts, to show all the things Forgejo did on their own. Things that matter to the average person who cares far less about the distinction between open core and free software than we do. Perhaps even commit to a period of remaining a drop-in replacement after becoming a hard fork (not a terribly long period, mind you).

In other words, from a developer perspective, I'd welcome a hard fork, because it would make things easier for me. From the perspective of someone who's less involved in development, and cares little about FLOSS politics and licensing... I think it would be too soon just yet for a hard fork in three months time - but then, I'm not such a person, so I'm relying on my imagination here a little. A bit of experimentation to see how well it would work out would make a lot of difference.

I'm a long-time Forgejo user (switched pretty much with the first release), and recently a contributor too. I have... mixed feelings. On one hand, I believe that a hard fork is eventually inevitable. I also believe that it is a step that should be taken long before it becomes inevitable. I also agree that in the long run - and likely in the short run too - it would benefit Forgejo a lot, it would give Forgejo more freedom to do what developers feel necessary, it might feel like loosing a set of chains. On the other hand, the question I keep asking myself is: is *this* the right time to make that step? Is three months enough? Perhaps a slower, more cautious plan might work better. One where the decision is not made "immediately" when a consensus is reached. Rather, it would be a bit of exploration at first: rather than a weekly rebase, do it every two weeks. Then start cherry picking inbetween rebases, and if all of those work out well, then stop rebasing. But even before that, get a release or two out, perhaps a couple of blog posts, to show all the things Forgejo did on their own. Things that matter to the average person who cares far less about the distinction between open core and free software than we do. Perhaps even commit to a period of remaining a drop-in replacement after becoming a hard fork (not a terribly long period, mind you). In other words, from a developer perspective, I'd welcome a hard fork, because it would make things easier for *me*. From the perspective of someone who's less involved in development, and cares little about FLOSS politics and licensing... I think it would be too soon just yet for a hard fork in three months time - but then, I'm not such a person, so I'm relying on my imagination here a little. A bit of experimentation to see how well it would work out would make a lot of difference.

I'm against a hard fork. I don't think it's a good idea to split the contributors into 2 projects. This will hurt more than it helps in the long term.

Could you please explain in more details your objections? In particular, how would that impact your work on Forgejo?

> I'm against a hard fork. I don't think it's a good idea to split the contributors into 2 projects. This will hurt more than it helps in the long term. Could you please explain in more details your objections? In particular, how would that impact your work on Forgejo?

From the perspective of someone who's less involved in development, and cares little about FLOSS politics and licensing... I think it would be too soon just yet for a hard fork in three months time...

The major selling points to Forgejo users will probably be the absence of regression and breaking changes. As well as a steady stream of new features. One simple example is agit: it is there, partly. What works and what does not? Reworking the documentation and adding a few tests to verify it actually behaves as documented is a low hanging fruit. And it can then be advertised as a usable feature instead of an easter-egg that may behave in unspecified and untested ways.

Bringing stability to Forgejo does not only mean that what works keep working, which is needed but boring. It also means that what is currently half baked or half broken gets fixed and becomes usable, which is literally what one expects of every new feature. Going from an experimental stage (which a number of features are in) to a stable stage.

> From the perspective of someone who's less involved in development, and cares little about FLOSS politics and licensing... I think it would be too soon just yet for a hard fork in three months time... The major selling points to Forgejo users will probably be the **absence** of regression and breaking changes. As well as a steady stream of **new features**. One simple example is `agit`: it is there, partly. What works and what does not? Reworking the documentation and adding a few tests to verify it actually behaves as documented is a low hanging fruit. And it can then be advertised as a usable feature instead of an easter-egg that may behave in unspecified and untested ways. Bringing stability to Forgejo does not only mean that what works keep working, which is needed but boring. It also means that what is currently half baked or half broken gets fixed and becomes usable, which is literally what one expects of every new feature. Going from an experimental stage (which a number of features are in) to a stable stage.

A message was deleted, send a mail to moderation@forgejo.org for more information.

A message was deleted, send a mail to moderation@forgejo.org for more information.

I was for a hard, copy-left fork since Forgejo's inception, but I'm only an occasional contributor, so I defer the decision to the main team.

As for readiness, I think Forgejo is well-prepared to handle the demands of new development and maintenance. But for timing, I'd recommend waiting till federation is in place. Because, if Forgejo's federation code finds its way to the Gitea codebase, then it won't be necessary for Forgejo to be a drop-in replacement to Gitea. It can have a different relationship with Gitea by federating with it.

I was for a hard, copy-left fork since Forgejo's inception, but I'm only an occasional contributor, so I defer the decision to the main team. As for readiness, I think Forgejo is well-prepared to handle the demands of new development and maintenance. But for timing, I'd recommend waiting till federation is in place. Because, if Forgejo's federation code finds its way to the Gitea codebase, then it won't be necessary for Forgejo to be a drop-in replacement to Gitea. It can have a different relationship with Gitea by federating with it.

Having federation will help users move from one instance to another and is going to be an additional migration path when a project wants to switch. Being a drop-in replacement is different in the sense that it does not require any operation from the admin or the user, just a replacement of the binary. Even if federation is fully production ready, it will not achieve that. For this reason, although I agree with you that federation mitigates the problem in a useful way, I do not think it should be a blocker.

Having federation will help users move from one instance to another and is going to be an additional migration path when a project wants to switch. Being a drop-in replacement is different in the sense that it does not require any operation from the admin or the user, just a replacement of the binary. Even if federation is fully production ready, it will not achieve that. For this reason, although I agree with you that federation mitigates the problem in a useful way, I do not think it should be a blocker.
Owner
Copy link

Thank you @earl-warren for bringing up this matter. I understand that it brings difficulties to discuss this here. I also propose to have Codeberg e.V. work out a position on the matter, since it is the official umbrella organization and a big user. I don't want it to be binding, but could be an interesting perspective to consider. It will, however, take some time.

I am a Forgejo user at scale, because I care for the systems at Codeberg. And I can only repeat on this occasion how happy I am about the switch. The Forgejo team started caring about our problems. Long-standing stability issues have been addressed. The handling of security communication was drastically improved. Support from the community is awesome.

In another position, I am also an involved contributor to Forgejo. I chat a lot with maintainers and developers, and I try to coordinate contributions from Codeberg. I see that a lot of time is spent on a maintenance burden which originates from the relationship to Gitea, namely the rebases but some more tasks (upstreaming and discussion changes, considering how to proceed in case of two different patches for the same problem etc).

To outsiders, it looks like Forgejo is only taking and rebranding. Under the hood, there's a lot going on. Forgejo's selling points are trust, stability, security, a good community, among other. And I am sure that we can make user experience one of them if we want to. The work on user research is a good next step that already started.

A big showstopper to Forgejo's progress is Gitea: The review process feels non-deterministic. I have the impression that people nit-pick contributions from Forgejo and go ahead with whatever mess is proposed from someone else. There appears to be no clear strategy on matters of security, on testing, and other topics where Forgejo maintainers want to find a concept for. Last but not least, one of the major problems is the lack of transparency. Even if guidelines exist, Forgejo doesn't have access, and thus cannot make educated decisions. We don't even know who is in the Gitea security team to improve collaboration.

After all, I think we should aim for not having external factors influence our development. The drop-in replacement to Gitea is a selling point, but in my eyes it is more important to have Forgejo developers being free to talk about refactors, testing and a lot more, independently of what Gitea does (or does not). We should not rush this decision, but experiment with our tooling. Does cherry-picking work? If not, we should continue with rebases in the meantime. Let's courageously try out our implementations if we disagree how upstream developers fix a problem. Do the advantages pay out?

If this path works out, there will be a day where we see that remaining compatible with Gitea is more work than an actual hard fork. This will be the day where Forgejo becomes a hard fork, in my opinion.

Let me add some final thoughts: Many people switched to Forgejo from Gitea. And those who know about Gitea but didn't switch likely have their reasons and won't make it in the next months. I think we should stop caring about those and ensure to make existing Forgejo users happy. Forgejo users likely care about our values, and we should strengthen them (security, stability, freedom).
Gitea, on the other hand, also has happy users. People who believe that companies make better product than communities. Their customers might just want to deploy their instance on Windows machines and Microsoft SQL Server to develop their proprietary game. The Gitea community is mostly fine on developing something on proprietary tooling (translations, GitHub etc). I think there is a fundamental difference in both communities and their goals, and we cannot and should not address both. It is good if we can make collaboration efficient (exchanging patches as long as possible), but not for every price. I have the impression that focusing on our users is more efficient with our time, so let's make this the top priority.

Thank you @earl-warren for bringing up this matter. I understand that it brings difficulties to discuss this here. I also propose to have Codeberg e.V. work out a position on the matter, since it is the official umbrella organization and a big user. I don't want it to be binding, but could be an interesting perspective to consider. It will, however, take some time. I am a Forgejo user at scale, because I care for the systems at Codeberg. And I can only repeat on this occasion how **happy I am about the switch.** The Forgejo team started caring about our problems. Long-standing stability issues have been addressed. The handling of security communication was drastically improved. Support from the community is awesome. In another position, I am also an involved contributor to Forgejo. I chat a lot with maintainers and developers, and I try to coordinate contributions from Codeberg. I see that a lot of time is spent on a **maintenance burden** which originates from the relationship to Gitea, namely the rebases but some more tasks (upstreaming and discussion changes, considering how to proceed in case of two different patches for the same problem etc). To outsiders, it looks like Forgejo is only taking and rebranding. Under the hood, there's a lot going on. Forgejo's **selling points are trust, stability, security, a good community**, among other. And I am sure that we can make **user experience** one of them if we want to. The work on user research is a good next step that already started. A big showstopper to Forgejo's progress is Gitea: The review process feels non-deterministic. I have the impression that people nit-pick contributions from Forgejo and go ahead with whatever mess is proposed from someone else. There appears to be no clear strategy on matters of security, on testing, and other topics where Forgejo maintainers want to find a concept for. Last but not least, one of the major problems is **the lack of transparency**. Even if guidelines exist, Forgejo doesn't have access, and thus cannot make educated decisions. We [don't even know who is in the Gitea security team](https://codeberg.org/forgejo/discussions/issues/86) to improve collaboration. After all, I think we should aim for **not having external factors influence our development**. The drop-in replacement to Gitea is a selling point, but in my eyes it is more important to have Forgejo developers being free to talk about refactors, testing and a lot more, independently of what Gitea does (or does not). We should **not rush this decision, but experiment** with our tooling. Does cherry-picking work? If not, we should continue with rebases in the meantime. Let's courageously try out our implementations if we disagree how upstream developers fix a problem. Do the advantages pay out? If this path works out, there will be a day where we see that remaining compatible with Gitea is more work than an actual hard fork. This will be the day where Forgejo becomes a hard fork, in my opinion. Let me add some final thoughts: Many people switched to Forgejo from Gitea. And those who know about Gitea but didn't switch likely have their reasons and won't make it in the next months. I think we should stop caring about those and ensure to make existing Forgejo users happy. Forgejo users likely care about our values, and we should strengthen them (security, stability, freedom). Gitea, on the other hand, also has happy users. People who believe that companies make better product than communities. Their customers might just want to deploy their instance on Windows machines and Microsoft SQL Server to develop their proprietary game. The Gitea community is mostly fine on developing something on proprietary tooling (translations, GitHub etc). I think there is a fundamental difference in both communities and their goals, and we cannot and should not address both. It is good if we can make collaboration efficient (exchanging patches as long as possible), but not for every price. I have the impression that focusing on our users is more efficient with our time, so let's make this the top priority.
Member
Copy link

From the beginning, I've been in favour of eventually becoming a hard fork, and I maintain that opinion. Certainly in terms of my own contributions (which recently have been few, and my planned bigger contributions much delayed), it would make life easier. I can only imagine how much easier it would make things for those who currently bear the responsibility of doing the weekly rebase. I'd love to see Forgejo move away from the rebase-based workflow and gain a bit more freedom.

As for the process and the timing, due to my current near absence from the project, I'll leave the decision up those who are more involved in maintaining the project on a day-to-day basis.

One idea (which Otto also mentioned) is that it might be good to experiment with a cherry-picking model alongside the rebasing model, for a short time. Of course, this would be even more work in the short term...

From the beginning, I've been in favour of eventually becoming a hard fork, and I maintain that opinion. Certainly in terms of my own contributions (which recently have been few, and my planned bigger contributions much delayed), it would make life easier. I can only imagine how much easier it would make things for those who currently bear the responsibility of doing the weekly rebase. I'd love to see Forgejo move away from the rebase-based workflow and gain a bit more freedom. As for the process and the timing, due to my current near absence from the project, I'll leave the decision up those who are more involved in maintaining the project on a day-to-day basis. One idea (which Otto also mentioned) is that it might be good to experiment with a cherry-picking model _alongside_ the rebasing model, for a short time. Of course, this would be even more work in the short term...

@caesar @fnetX @algernon the notion of getting more familiar with the newer workflow before being committed to it is a sound suggestion. When I wrote that Forgejo is currently already about 50% a hard fork, I believe it is exactly what you suggest. I realize it may not be trivial to see that at first glance but it started happening over six months ago.

The simpler example of that is the documentation. You will see that before every major release there are a number of PRs that cherry-pick bits and pieces from Gitea and Codeberg, integrating them with the Forgejo documentation. Another example, code side, is the Forgejo runner which shares a lot of code with the Gitea runner but has seen an order of magnitude more commits in the past six months. On a regular basis the changes from the Gitea runner are integrated in the Forgejo runner, as long as they do no interfere. And if they do, they are discarded, which is the opposite of what Forgejo does currently: favor Gitea changes to reduce the chances of conflicts.

I would also like to emphasize that the weekly cleanup is not an issue or a burden. It will be replaced by an equivalent amount of work, only doing things differently. From this perspective I don't expect the workload to change much, only its specifics. In both cases (rebase or cherry-pick) it is about observing carefully the Forgejo dependencies and re-using as much as possible to improve the codebase. I would not mind continuing with the weekly cleanup in the long run. It is well organized and has always been completed without stress (even in the most daunting cases) within half a day.

The more I think about it the more I'm convinced that the primary motivation and benefit of completing this last step to a hard fork is to put an end to the recurring regressions and the unchecked accumulation of technical debt. It will make everyone happier and more efficient, users and developers alike.

@caesar @fnetX @algernon the notion of getting more familiar with the newer workflow before being committed to it is a sound suggestion. When I wrote that Forgejo is currently already about 50% a hard fork, I believe it is exactly what you suggest. I realize it may not be trivial to see that at first glance but it started happening over six months ago. The simpler example of that is the documentation. You will see that before every major release there are a number of PRs that cherry-pick bits and pieces from Gitea and Codeberg, integrating them with the Forgejo documentation. Another example, code side, is the Forgejo runner which shares a lot of code with the Gitea runner but has seen an order of magnitude more commits in the past six months. On a regular basis the changes from the Gitea runner are integrated in the Forgejo runner, as long as they do no interfere. And if they do, they are discarded, which is the opposite of what Forgejo does currently: favor Gitea changes to reduce the chances of conflicts. I would also like to emphasize that the weekly cleanup is not an issue or a burden. It will be replaced by an equivalent amount of work, only doing things differently. From this perspective I don't expect the workload to change much, only its specifics. In both cases (rebase or cherry-pick) it is about observing carefully the Forgejo dependencies and re-using as much as possible to improve the codebase. I would not mind continuing with the weekly cleanup in the long run. It is well organized and has always been completed without stress (even in the most daunting cases) within half a day. The more I think about it the more I'm convinced that the primary motivation and benefit of completing this last step to a hard fork is to put an end to the recurring regressions and the unchecked accumulation of technical debt. It will make everyone happier and more efficient, users and developers alike.

A message was deleted, send a mail to moderation@forgejo.org for more information.

A message was deleted, send a mail to moderation@forgejo.org for more information.

From this issue, as well as the other one its more than clear, at least for me, that its highest time for Forgejo to become hard-fork. Their way of "collaboration" differs from the one of Forgejo and, if followed, will do more harm than good to Forgejo.

My 2p's

From this issue, as well as [the other one](https://codeberg.org/forgejo/discussions/issues/86) its more than clear, at least for me, that its highest time for Forgejo to become **hard-fork**. Their way of "collaboration" differs from the one of Forgejo and, if followed, will do more harm than good to Forgejo. My 2p's
Owner
Copy link

@JakobDev I explicitly want to address the concerns you raised in #96 (comment)

split the contributors into 2 projects

In a sense, I think that the contributors are basically already split. Without a deep analysis, I think that you and @delvh are the only two contributors to both projects. Everyone else seems to have chosen a side. I acknowledge your work, and I understand that having Forgejo become a hard fork over time is likely not in your interest. Thank you for being involved in both projects so far.

However, with my arguments from #96 (comment) I still believe that the current situation puts more stress on most people who contribute to Forgejo, and there are severe issues in the collaboration with Gitea-as-a-project that hinder Forgejo's success, the worst is security (#86).

Since Forgejo and Gitea likely serve different user bases (freedom, trust, stability, security vs enterprice solutions and pace of new features), do you agree that the time will come to separate the products and have each one become more appealing to its specific community?

@JakobDev I explicitly want to address the concerns you raised in https://codeberg.org/forgejo/discussions/issues/96#issuecomment-1422904 > split the contributors into 2 projects In a sense, I think that the contributors are basically already split. Without a deep analysis, I think that you and @delvh are the only two contributors to both projects. Everyone else seems to have chosen a side. I acknowledge your work, and I understand that having Forgejo become a hard fork over time is likely not in your interest. Thank you for being involved in both projects so far. However, with my arguments from https://codeberg.org/forgejo/discussions/issues/96#issuecomment-1423515 I still believe that the current situation puts more stress on most people who contribute to Forgejo, and there are severe issues in the collaboration with Gitea-as-a-project that hinder Forgejo's success, the worst is security (https://codeberg.org/forgejo/discussions/issues/86). Since Forgejo and Gitea likely serve different user bases (freedom, trust, stability, security vs enterprice solutions and pace of new features), do you agree that the time will come to separate the products and have each one become more appealing to its specific community?
Member
Copy link

I agree in doing experiments with cherry picking. This will make my/our contribution work more easy. But if this means, the effort to stay somehow in sync will become to large, it is also okay to us to continue the current way.

Regarding the type of fork, I think sooner or later we will have an hard fork. To find the best point in time to switch over we can maybe find a way to measure the energy we get from and investing into gitea?

Eg. count the amount of (useful and tested) changes in opposite to our invests in discuss OwnerShip-Comments, fixes for low quality features, mitigation of security risks, rebase efforts for contributors, ...

Such a measure will found our decision ...

I agree in doing experiments with cherry picking. This will make my/our contribution work more easy. But if this means, the effort to stay somehow in sync will become to large, it is also okay to us to continue the current way. Regarding the type of fork, I think sooner or later we will have an hard fork. To find the best point in time to switch over we can maybe find a way to measure the energy we get from and investing into gitea? Eg. count the amount of (useful and tested) changes in opposite to our invests in discuss OwnerShip-Comments, fixes for low quality features, mitigation of security risks, rebase efforts for contributors, ... Such a measure will found our decision ...

I think that you and @delvh are the only two contributors to both projects.

I would rather say intentional contributor. At the moment, Forgejo is still a soft fork of Gitea, so every Gitea contributor is also a Forgejo contributor, even if he don't know Forgejo exists. Gitea has currently more contributors. If we do a hard fork and the Codebase becomes different, we can longer use these contributions. So if a Feature gets added to Gitea that is also requested by Forgejo Users, we need to implement it for Forgejo on our own. That put more work on Forgejo contributors at the end.

Since Forgejo and Gitea likely serve different user bases (freedom, trust, stability, security vs enterprice solutions and pace of new features), do you agree that the time will come to separate the products and have each one become more appealing to its specific community?

Most people will use what fits their needs. The Philosophy of the projects comes after that, if it even considered. Gitea is still OpenSoucre, so that's not a blocker for Users who don't want proprietary stuff running on their Server. Forgejo has all features of Gitea a the Moment, so you can choose by Philosophy, but when Gitea starts getting more Features, that Users are interested in and that are not in Forgejo because of the hard fork, they will prefer Gitea. Only those for whom Philosopy is particularly important will keep using Forgejo.

> I think that you and @delvh are the only two contributors to both projects. I would rather say intentional contributor. At the moment, Forgejo is still a soft fork of Gitea, so every Gitea contributor is also a Forgejo contributor, even if he don't know Forgejo exists. Gitea has currently more contributors. If we do a hard fork and the Codebase becomes different, we can longer use these contributions. So if a Feature gets added to Gitea that is also requested by Forgejo Users, we need to implement it for Forgejo on our own. That put more work on Forgejo contributors at the end. > Since Forgejo and Gitea likely serve different user bases (freedom, trust, stability, security vs enterprice solutions and pace of new features), do you agree that the time will come to separate the products and have each one become more appealing to its specific community? Most people will use what fits their needs. The Philosophy of the projects comes after that, if it even considered. Gitea is still OpenSoucre, so that's not a blocker for Users who don't want proprietary stuff running on their Server. Forgejo has all features of Gitea a the Moment, so you can choose by Philosophy, but when Gitea starts getting more Features, that Users are interested in and that are not in Forgejo because of the hard fork, they will prefer Gitea. Only those for whom Philosopy is particularly important will keep using Forgejo.

@JakobDev thanks for articulating your point of view clearly. One last question: what is your opinion on how a hard fork helps or does not help prevent regressions from happening in the Forgejo codebase?

@JakobDev thanks for articulating your point of view clearly. One last question: what is your opinion on how a hard fork helps or does not help prevent regressions from happening in the Forgejo codebase?

I can see especially the following problem at the moment:

I know, the relation to wxiaoguang is strained (in both directions, no matter who I'm talking with) but to summarize wxiaoguang's most common PR comments, it's most often something like does not adhere to style guidelines or won't work for <x> reason.
What I've seen are almost always factual shortcomings that were perhaps expressed too bluntly.

And exactly this is why I think Forgejo will crash hard if it decides to hard-fork:
While it may work for some time, I have to say that QA and knowledge of the software needs to be improved tremendously.
Forgejo already does a good job at creating tests.
I agree, Gitea desperately needs more of those.

Nevertheless, tests aren't everything:
If Forgejo would hard-fork and there are no significant changes in how PRs are reviewed, then Forgejo will become an unmaintainable mess in about two to three years.
It took Gitea long enough to establish serious PR reviewing, see for example the Gogs leftovers we still stumble over.
Since then, its quality has become much better (new features rarely introduce unexpected behavior).
Before that, a lot of technical debt had been acquired that is now slowly getting cleaned up over time, a process that is still ongoing.

However, Forgejo currently seems to make the same mistakes that Gitea made in the beginning.
So, as I see it: Of course, it's possible to hard-fork but I wish you a lot of luck with successfully maintaining Forgejo then as from what I've seen, Forgejo is not yet equipped to maintain itself.

I can see especially the following problem at the moment: I know, the relation to wxiaoguang is strained (in both directions, no matter who I'm talking with) but to summarize wxiaoguang's most common PR comments, it's most often something like `does not adhere to style guidelines` or `won't work for <x> reason`. What I've seen are almost always factual shortcomings that were perhaps expressed too bluntly. And exactly this is why I think Forgejo will crash hard if it decides to hard-fork: While it may work for some time, I have to say that QA and knowledge of the software needs to be improved tremendously. Forgejo already does a good job at creating tests. I agree, Gitea desperately needs more of those. Nevertheless, tests aren't everything: If Forgejo would hard-fork and there are no significant changes in how PRs are reviewed, then Forgejo will become an unmaintainable mess in about two to three years. It took Gitea long enough to establish serious PR reviewing, see for example the Gogs leftovers we still stumble over. Since then, its quality has become much better (new features rarely introduce unexpected behavior). Before that, a lot of technical debt had been acquired that is now slowly getting cleaned up over time, a process that is still ongoing. However, Forgejo currently seems to make the same mistakes that Gitea made in the beginning. So, as I see it: Of course, it's possible to hard-fork but I wish you a lot of luck with successfully maintaining Forgejo then as from what I've seen, Forgejo is not yet equipped to maintain itself.
Member
Copy link

If Forgejo would hard-fork and there are no significant changes in how PRs are reviewed, then Forgejo will become an unmaintainable mess in about two to three years.

Before that, a lot of technical debt had been acquired that is now slowly getting cleaned up over time, a process that is still ongoing.

While it may work for some time, I have to say that QA and knowledge of the software needs to be improved tremendously.

[...] tests aren't everything
Forgejo already does a good job at creating tests.

+1, with a mild disagreement on the QA part.

EDIT: The +1 refers to the statements I quoted. I do not have an opinion and/or partially disagree with the other statements mentioned. I find the review process OK, but I am not sure if the pace can be kept up with.

> If Forgejo would hard-fork and there are no significant changes in how PRs are reviewed, then Forgejo will become an unmaintainable mess in about two to three years. > Before that, a lot of technical debt had been acquired that is now slowly getting cleaned up over time, a process that is still ongoing. > While it may work for some time, I have to say that QA and knowledge of the software needs to be improved tremendously. > [...] tests aren't everything > Forgejo already does a good job at creating tests. +1, with a mild disagreement on the QA part. EDIT: The +1 refers to the statements I quoted. I do not have an opinion and/or partially disagree with the other statements mentioned. I find the review process OK, but I am not sure if the pace can be kept up with.

@devlh thanks for articulating your observations.

This is a very severe criticism of the Forgejo development and review process, but it is expressed in a respectful way and I will not debate its merits. You are entitled to your opinion and I find best that it happens in Forgejo space, where it can be taken as a constructive input.

You have not contributed to the forgejo repository, either in code or in reviews and I'm sure your participation would have made a difference, specially to improve the situation where it is needed the most . But you are a Gitea maintainer, nominated to sit on the TOC in 2024 and, as @fnetX wrote, one of the few who participate in discussions in Forgejo spaces.

Whatever is decided regarding the hard fork will not have an impact on you since you are not using Forgejo and you will keep working on the Gitea codebase as you always did either way. Regardless, I want to re-iterate that I respect and appreciate you expressing your opinion.

@devlh thanks for articulating your observations. This is a very severe criticism of the Forgejo development and review process, but it is expressed in a respectful way and I will not debate its merits. You are entitled to your opinion and I find best that it happens in Forgejo space, where it can be taken as a constructive input. You have not contributed to the forgejo repository, either in code or in reviews and I'm sure your participation would have made a difference, specially to improve the situation where it is needed the most . But you are a Gitea maintainer, nominated to sit on the TOC in 2024 and, as @fnetX wrote, one of the few who participate in discussions in Forgejo spaces. Whatever is decided regarding the hard fork will not have an impact on you since you are not using Forgejo and you will keep working on the Gitea codebase as you always did either way. Regardless, I want to re-iterate that I respect and appreciate you expressing your opinion.
Owner
Copy link

if a Feature gets added to Gitea that is also requested by Forgejo Users, we need to implement it for Forgejo on our own

If Forgejo becomes a hard fork, it does not immediately tell a thing about how far the codebase diverges. I think there will be a period where it is possible to port relevant features and bugfixes rather than re-implement them. It will, however, allow to choose wisely, and optionally not accept features that do not meet certain criteria.

I do believe that there is a sweet spot (between keeping the current soft-fork model with rebases and becoming a hard fork that diverges heavily), which allows us to minimize the effort spent on discussions and conflicts and optimizes the energy invested by Forgejo maintainers.

> if a Feature gets added to Gitea that is also requested by Forgejo Users, we need to implement it for Forgejo on our own If Forgejo becomes a hard fork, it does not immediately tell a thing about how far the codebase diverges. I think there will be a period where it is possible to port relevant features and bugfixes rather than re-implement them. It will, however, allow to choose wisely, and optionally not accept features that do not meet certain criteria. I do believe that there is a sweet spot (between keeping the current soft-fork model with rebases and becoming a hard fork that diverges heavily), which allows us to minimize the effort spent on discussions and conflicts and optimizes the energy invested by Forgejo maintainers.

The whispering of a hard fork of Gitea have been happening even before the idea of Forgejo was around. Those talks before Forgejo never resulted in an actual hard fork, because at the end of the day, it was just unpractical to do so. The talks actually didn't stop when Forgejo was launched, because most of the legwork was now there to independently develop a forge. Yet the talks still resulted in no hard fork. They simply didn't result in a hard fork due to the simple fact that the reasons for a hard fork were seen as issues 'in the heat of the moment'1 .

Forgejo has now existed for more than a year and I think most, including myself, have reflected upon Forgejo at some point. In my personal reflection I've noticed that the reasons that were previously seen as temporary, maybe even stylish, issues have progressed to becoming a more permanent, maybe even ideological, issues. I've tried to stay silent in public around these issues as I believed they were temporary/'in the heat of the moment', therefore my involvement could simply add more fuel to the pile. My perspective has changed on this matter, staying silent and not trying to drive issues/discussions towards a solution will do more harm than good, hence why I'm trying express my opinion here.

Forgejo should aim to develop a forge, but there are issues forming or that already have formed2 that I see as blockers to this goal. I see them as a blocker, because contributors who want to contribute to Forgejo are exposed to Forgejo's relationship with Gitea3 and cannot just focus on technical aspects of Forgejo. Under the hood in Forgejo I've seen a shift that more time is now being spent strategizing instead of being spent to work on Forgejo.

Nobody has a good understanding of what the average Forgejo user is or wants, but that doesn't matter anymore if Forgejo contributors are not engaging with them, because they are spending more of their time arguing issues that arise from the same foundation.

I want to stop for a minute and ask if a hard-fork is the right solution for this proposal/roadblock. I'm going on a limb here to say that the whispering about a hard fork have been foreshadowing for a moment such as now. The problems are articulated, the 'in the heat of the moment' issues have progressed to become permanent and previous discussions, such as the security one, have not led to an improvement.

A hard fork will blow most of these issues right of the table, because the foundation that have allowed for such issues to arise would be removed from the Forgejo project. I think enough time has been allocated to come up with individual solutions to the longer-standing issues, but no solutions has come out of it and tackling them one by one is not a viable option.

  1. To clarify these in the heat of the moment issues were most if not all directly linked to some annoyance with Gitea's codebase or maintainers. ↩︎

  2. I refer to @earl-warren & @fnetX comments for the technical and social aspect, respectively. ↩︎

  3. A prime examples is that "Hey thank you for your fix and time that you have putted into this, but Gitea has suddenly a different solution for this problem. That means the time you've put into this will now be voided" is a sad reality for a surprising handful of PRs. ↩︎

The whispering of a hard fork of Gitea have been happening even before the idea of Forgejo was around. Those talks before Forgejo never resulted in an actual hard fork, because at the end of the day, it was just unpractical to do so. The talks actually didn't stop when Forgejo was launched, because most of the legwork was now there to independently develop a forge. Yet the talks still resulted in no hard fork. They simply didn't result in a hard fork due to the simple fact that the reasons for a hard fork were seen as issues 'in the heat of the moment'[^0]. Forgejo has now existed for more than a year and I think most, including myself, have reflected upon Forgejo at some point. In my personal reflection I've noticed that the reasons that were previously seen as temporary, maybe even stylish, issues have progressed to becoming a more permanent, maybe even _ideological_, issues. I've tried to stay silent in public around these issues as I believed they were temporary/'in the heat of the moment', therefore my involvement could simply add more fuel to the pile. My perspective has changed on this matter, staying silent and not trying to drive issues/discussions towards a solution will do more harm than good, hence why I'm trying express my opinion here. Forgejo should aim to develop a forge, but there are issues forming or that already have formed[^1] that I see as blockers to this goal. I see them as a blocker, because contributors who want to contribute to Forgejo are exposed to Forgejo's relationship with Gitea[^2] and cannot just focus on technical aspects of Forgejo. Under the hood in Forgejo I've seen a shift that more time is now being spent strategizing instead of being spent to work on Forgejo. Nobody has a good understanding of what the _average_ Forgejo user is or wants, but that doesn't matter anymore if Forgejo contributors are not engaging with them, because they are spending more of their time arguing issues that arise from the same foundation. I want to stop for a minute and ask if a hard-fork is the right solution for this proposal/roadblock. I'm going on a limb here to say that the whispering about a hard fork have been foreshadowing for a moment such as now. The problems are articulated, the 'in the heat of the moment' issues have progressed to become permanent and previous discussions, such as [the security one](https://codeberg.org/forgejo/discussions/issues/86), have not led to an improvement. A hard fork will blow most of these issues right of the table, because the foundation that have allowed for such issues to arise would be removed from the Forgejo project. I think enough time has been allocated to come up with individual solutions to the longer-standing issues, but no solutions has come out of it and tackling them one by one is not a viable option. [^0]: To clarify these in the heat of the moment issues were most if not all directly linked to some annoyance with Gitea's codebase or maintainers. [^1]: I refer to @earl-warren & @fnetX comments for the technical and social aspect, respectively. [^2]: A prime examples is that "Hey thank you for your fix and time that you have putted into this, but Gitea has _suddenly_ a different solution for this problem. That means the time you've put into this will now be voided" is a sad reality for a surprising handful of PRs.

foundation that have allowed for such issues to arise would be removed from the Forgejo project.

@Gusted what do you mean by this?

> foundation that have allowed for such issues to arise would be removed from the Forgejo project. @Gusted what do you mean by this?

I think switching to a simpler development workflow is the best option, today.

A year ago I strongly advocated against it because it was much more beneficial for Forgejo, overall, to be a set of patches on top of Gitea. But things have changed, a lot. Some people may still think Forgejo is a set of patches on top of Gitea, but take a closer look and it will quickly become clear that it has not been the case for quite some time.

There are concerns about Forgejo momentum, the pace at which features can be produced being one of them. But Forgejo is and will be the underdog for years before federation spreads. It does not matter how many features it tries to add, it will never be able to compete with tech giants like GitLab or GitHub.

The only sound approach is for Forgejo to be the better version of itself going forward. And today I strongly support the move to a hard fork because it is the only way to achieve that goal, for all the reasons, technical, social & philosophical laid out here.

I think switching to a simpler development workflow is the best option, today. A year ago I strongly advocated against it because it was much more beneficial for Forgejo, overall, to be a set of patches on top of Gitea. But things have changed, a lot. Some people may still think Forgejo is a set of patches on top of Gitea, but take a closer look and it will quickly become clear that it has not been the case for quite some time. There are concerns about Forgejo momentum, the pace at which features can be produced being one of them. But Forgejo is and will be the underdog for years before federation spreads. It does not matter how many features it tries to add, it will never be able to compete with tech giants like GitLab or GitHub. The only sound approach is for **Forgejo to be the better version of itself going forward. And today I strongly support the move to a hard fork** because it is the only way to achieve that goal, for all the reasons, technical, social & philosophical laid out here.
Member
Copy link

And today I strongly support the move to a hard fork because it is the only way to achieve that goal, for all the reasons, technical, social & philosophical laid out here.

I am worried about the following: Does Forgejo have a "transition" plan (even if that's just "let's just hard-fork it starting from the next version and selectively cherry-pick the stuff that we are missing from newly introduced features that have not matured yet))? Would this mean that Forgejo would spend time selectively rebasing changes on top of Gitea, and not a 100% "we develop everything by ourselves"-type-of-deal?

Is the time now? Would Forgejo wait until a specific release or a specific milestone for this to be complete?

> And today I strongly support the move to a hard fork because it is the only way to achieve that goal, for all the reasons, technical, social & philosophical laid out here. I am worried about the following: Does Forgejo have a "transition" plan (even if that's just "let's just hard-fork it starting from the next version and selectively cherry-pick the stuff that we are missing from newly introduced features that have not matured yet))? Would this mean that Forgejo would spend time selectively rebasing changes on top of Gitea, and not a 100% "we develop everything by ourselves"-type-of-deal? Is the time **now**? Would Forgejo wait until a specific release or a specific milestone for this to be complete?

If a decision is made I suspect it will take months to materialize concretely. There is no rush and it can be done in a way that will be transparent. In case you missed it, there is also a comment that explains that a large part of Forgejo is already a hard fork, it happened gradually on areas where the decision did not have a major impact. This is the last step rather than the first step.

As to how it will happen concretely if it is decided, this is a fair question.

I don't know for other people but, as I pointed out earlier, I spend about half a day every week caring to reconcile the Gitea and Forgejo codebase, what I affectionately call the weekly cleanup. I intend to keep doing that after the hard fork is decided and the outcome will be a set of commits cherry picked from Gitea onto Forgejo. As opposed what it is now: a set of commits cherry-picked from Forgejo onto Gitea.

How would that work for stable releases? Pretty much as it currently does because the stable branches of Forgejo are already hard forked from Gitea, starting with v1.20. A decision was made about six months ago to go this way and it turned out fine. There are detailed notes in the issue associated with each release where you can get concrete examples of what it entails.

But this is just me and each Forgejo contributor will be impacted differently.

If a decision is made I suspect it will take months to materialize concretely. There is no rush and it can be done in a way that will be transparent. In case you missed it, there is [also a comment](https://codeberg.org/forgejo/discussions/issues/96#issuecomment-1424429) that explains that a large part of Forgejo is already a hard fork, it happened gradually on areas where the decision did not have a major impact. This is the last step rather than the first step. As to how it will happen concretely if it is decided, this is a fair question. I don't know for other people but, as I pointed out earlier, I spend about half a day every week caring to reconcile the Gitea and Forgejo codebase, what I affectionately call the [weekly cleanup](https://codeberg.org/forgejo/forgejo/milestones?sort=furthestduedate&state=closed&q=cleanup). I intend to keep doing that after the hard fork is decided and the outcome will be a set of commits cherry picked from Gitea onto Forgejo. As opposed what it is now: a set of commits cherry-picked from Forgejo onto Gitea. How would that work for stable releases? Pretty much as it currently does because the **stable branches of Forgejo are already hard forked from Gitea**, starting with v1.20. A decision was made about six months ago to go this way and it turned out fine. There are detailed notes in the issue associated with each release where you can get concrete examples of what it entails. But this is just me and each Forgejo contributor will be impacted differently.

what do you mean by this?

@macfanpl Gitea being an unconditional external factor on Forgejo.

> what do you mean by this? @macfanpl Gitea being an unconditional external factor on Forgejo.

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.

After re-reading the comments in full and in light of the discussions I had in the past few days, here is a revised proposal. It is a decision that needs to be made carefully, considering all aspects, because there is no turning back. I'm under the impression that all arguments, in favor or against, have been covered. The implementation of this decision is, however, very simple. Before turning this into a formal governance decision, I'd like to get a feeling of whether the discussion must keep going instead.

If you actively participate in the making of Forgejo, could you please:

add 👍 to this comment if you think it is time to propose a governance decision to make Forgejo a hard fork
add 👀 to this comment if you think the discussion must continue before taking this formal step

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 drop-in replacement Gitea is not going to be possible at some point

Transition

It has been suggested to have a transition phase to get familiar with how different it will be. Fortunately there are a number of parts in Forgejo that already are independent from Gitea and they have been a training ground to prepare for the last and more significant step.

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 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 have not changed for a long time.

Benefits

Primarily

Secondarily

  • It allows to not be impacted by Gitea shady security behavior
  • It is more friendly to casual contributors compared to the current workflow
  • It allows to make architectural changes
  • 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

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
After re-reading the comments in full and in light of the discussions I had in the past few days, here is a revised proposal. It is a decision that needs to be made carefully, considering all aspects, because there is no turning back. I'm under the impression that all arguments, in favor or against, have been covered. The implementation of this decision is, however, very simple. Before turning this into a formal governance decision, I'd like to get a feeling of whether the discussion must keep going instead. **If you actively participate in the making of Forgejo**, could you please: add 👍 to this comment if you think it is time to propose a governance decision to make Forgejo a hard fork add 👀 to this comment if you think the discussion must continue before taking this formal step --- ## 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 drop-in replacement Gitea is not going to be possible at some point ## Transition It has been suggested to have a transition phase to get familiar with how different it will be. Fortunately there are a number of parts in Forgejo that already are independent from Gitea and they have been a training ground to prepare for the last and more significant step. 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 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 have not changed for a long time. ## 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) * Forgejo already has a large number of parts that were either created from scratch (the release process) or are developed independently of Gitea (documentation, Forgejo runner, ...). **It is not the first step to a hard fork, it is the last step.** ### Secondarily * It allows to not be impacted by [Gitea shady security behavior](https://codeberg.org/forgejo/website/issues/392) * 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 * 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 ## 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
earl-warren changed title from (削除) Proposal for a simpler development workflow (削除ここまで) to Proposal for a simpler development workflow / hard fork 2024年01月14日 01:04:33 +01:00

I would encourage the Forgejo project and it's members to mature onto their own path.

"The unknown is also the realm of infinite potential" 😃

just a quote of from reddit:
"I forgot about the Forgejo fork. Have they made any major improvements over Gitea yet?"

I was wondering from the beginning why this path eventually switching back from forgejo to gitea again is such a must have feature, but for real this doesn't seem to make any sense to me as users always can move all their repos and if a hosting admin of an significant userbase would ever be in the situation to have made a complete switch and what reason would make them revert this decision and whats thats forgejos responsibility to keep their own value that low in the first place that in most cases one would never switch when the only distinct feature is that it doesnt matter.. yes that licensing thing, but thats not a selling point to consider making that effort is it?

there is a niche to stand out from gitea a be a good alternative to gitlab as they seem to just dont care about their ce..

I would encourage the Forgejo project and it's members to mature onto their own path. "The unknown is also the realm of infinite potential" 😃 just a quote of from reddit: "I forgot about the Forgejo fork. Have they made any major improvements over Gitea yet?" I was wondering from the beginning why this path eventually switching back from forgejo to gitea again is such a must have feature, but for real this doesn't seem to make any sense to me as users always can move all their repos and if a hosting admin of an significant userbase would ever be in the situation to have made a complete switch and what reason would make them revert this decision and whats thats forgejos responsibility to keep their own value that low in the first place that in most cases one would never switch when the only distinct feature is that it doesnt matter.. yes that licensing thing, but thats not a selling point to consider making that effort is it? there is a niche to stand out from gitea a be a good alternative to gitlab as they seem to just dont care about their ce..

A formal agreement proposal was posted in the governance issue tracker.

A formal agreement proposal was [posted in the governance issue tracker](https://codeberg.org/forgejo/governance/issues/58).
Owner
Copy link

I still wanted to address the comment by @delvh here: #96 (comment)

Thank you for articulating your thoughts. The relation to wx* is not the topic, but I'd explicitly take this as an argument in favour of a fork (hopefully leading to a more friendly environment).

If Forgejo would hard-fork and there are no significant changes in how PRs are reviewed, then Forgejo will become an unmaintainable mess in about two to three years.

Can you elaborate on this? I am not aware of deficiencies in how pull requests are reviewed. I am not a maintainer in Forgejo code-wise, so I can only look at the end result. Speaking as a Codeberg admin, the delivered software product has improved a lot since Forgejo came into existence. We have been made aware of regressions and workarounds, bugs have been handled more efficiently. Upstream developments have been critically monitored. When I watch how the technical debt is managed within the Forgejo project, I have much more confidence in Forgejo than in Gitea, so I would be really interested to learn more about your perspective.

I don't have metrics at hand, but from my spectations, the Forgejo project spends more time on improving the quality of the software through bugfixes and security analysis than in Gitea, where a lot of time is spend in new features. Both are valid strategies, but I wonder how your impression differs so heavily from mine.

I would love to read more about how Forgejo can improve the review cycle. I do not recall having read any specific criticism so far, so feel free to share what you have to say so that this matter can be improved here, maybe similarly how a requirement for software tests was proposed.

I still wanted to address the comment by @delvh here: https://codeberg.org/forgejo/discussions/issues/96#issuecomment-1426808 Thank you for articulating your thoughts. The relation to wx* is not the topic, but I'd explicitly take this as an argument in favour of a fork (hopefully leading to a more friendly environment). > If Forgejo would hard-fork and there are no significant changes in how PRs are reviewed, then Forgejo will become an unmaintainable mess in about two to three years. Can you elaborate on this? I am not aware of deficiencies in how pull requests are reviewed. I am not a maintainer in Forgejo code-wise, so I can only look at the end result. Speaking as a Codeberg admin, the delivered software product has improved a lot since Forgejo came into existence. We have been made aware of regressions and workarounds, bugs have been handled more efficiently. Upstream developments have been critically monitored. When I watch how the technical debt is managed within the Forgejo project, I have much more confidence in Forgejo than in Gitea, so I would be really interested to learn more about your perspective. I don't have metrics at hand, but from my spectations, the Forgejo project spends more time on improving the quality of the software through bugfixes and security analysis than in Gitea, where a lot of time is spend in new features. Both are valid strategies, but I wonder how your impression differs so heavily from mine. I would love to read more about how Forgejo can improve the review cycle. I do not recall having read any specific criticism so far, so feel free to share what you have to say so that this matter can be improved here, maybe similarly how a [requirement for software tests](https://codeberg.org/forgejo/governance/pulls/51) was proposed.

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.
Owner
Copy link

By the way, I split some of the arguments I initially wanted to add to this discussion to a separate thread about sending patches to Gitea vs Forgejo. I believe that this is the first step before a hard-fork. It allows to gather facts that help making this decision.

Last but not least, we should in any case try to make certain guarantees and communicate them openly, before there is any chance for panic: We could guarantee that Forgejo will incorporate most of Gitea's work for at least x months. We should also guarantee a timespam where Forgejo will remain a drop-in-replacement to Gitea. (I also do believe that we should try to provide an upgrade path from Gitea for as long as possible. It is still a selling point. However, I have never heard of anyone switching back from Forgejo to Gitea, so I think that the other direction is not necessary to support when technically difficult).

By the way, I split some of the arguments I initially wanted to add to this discussion to a [separate thread about sending patches to Gitea vs Forgejo](https://codeberg.org/forgejo/discussions/issues/99). I believe that this is the first step before a hard-fork. It allows to gather facts that help making this decision. Last but not least, we should in any case try to make certain guarantees and communicate them openly, before there is any chance for panic: We could guarantee that Forgejo will incorporate most of Gitea's work for at least x months. We should also guarantee a timespam where Forgejo will remain a drop-in-replacement to Gitea. (I also do believe that we should try to provide an upgrade path from Gitea for as long as possible. It is still a selling point. However, I have never heard of anyone switching back from Forgejo to Gitea, so I think that the other direction is not necessary to support when technically difficult).

I agree and it has been the spirit of Forgejo since the start: working to facilitate the migration from Gitea as much as possible. It is worth noting though that since Gitea turned Open Core it is already engaged in strategies that trap the users and admins alike, luring them into thinking it is all for their benefit. Once someone falls in this trap, Forgejo cannot help them anymore, it is entirely out of its control. For instance there is an active advertisement campaign to encourage people to switch to Gitea Cloud (it is mentioned on every occasion, in the blogs, in the release announcements, in the documentation, on the web site). Once an admin is running in Gitea Cloud, it is already impossible for them to migrate to Forgejo. Or even to migrate to the Free Software version of Gitea for that matter.

I agree and it has been the spirit of Forgejo since the start: working to facilitate the migration from Gitea as much as possible. It is worth noting though that since Gitea turned Open Core it is already engaged in strategies that trap the users and admins alike, luring them into thinking it is all for their benefit. Once someone falls in this trap, Forgejo cannot help them anymore, it is entirely out of its control. For instance there is an active advertisement campaign to encourage people to switch to Gitea Cloud (it is mentioned on every occasion, in the blogs, in the release announcements, in the documentation, on the web site). Once an admin is running in Gitea Cloud, it is **already** impossible for them to migrate to Forgejo. Or even to migrate to the Free Software version of Gitea for that matter.
Owner
Copy link

With the decision to hardfork, Forgejo has adoped a much better development workflow. I'm happy to see a subjective increase in productivity, and my motivation to contribute to the project has increased.

@earl-warren thank you for bringing this up! I am closing the issue, because the actionable part is gone.

With the decision to hardfork, Forgejo has adoped a much better development workflow. I'm happy to see a subjective increase in productivity, and my motivation to contribute to the project has increased. @earl-warren thank you for bringing this up! I am closing the issue, because the actionable part is gone.
Sign in to join this conversation.
No Branch/Tag specified
No results found.
No results found.
Labels
Clear labels
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
14 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
forgejo/discussions#96
Reference in a new issue
forgejo/discussions
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?