Integration of the gitea changes inside forgejo #108

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

In the forgejo/governance#58 agreement, a couple of comments where concerned with the compatibility/feature-parity of forgejo with gitea if the workflow is changed from weekly-rebase to cherry-picking. They were has been addressed with the following paragraph:

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.

The weekly-rebase workflow "Furnace cleanup" has been steadily managed by @earl-warren (thank you for this!!).

If the agreement is accepted, this workflow will have to change, since making a git pull will not simply indicate which commits of gitea have been considered or not (we may want to not apply some commits, because the issue does not concern forgejo or was addressed by another mean).

Suggested solutions by @wetneb

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

I agree that having one place to discuss every change of gitea would be very useful, since it allows to document the fate of the change (addressed in commit XXX / cherry-picked in commit YYY ...).

However I think that it would make the number of PRs in forgejo too large.

I would suggested instead to create a dedicated forgejo/gitea repo, with automation to open an Issue everytime a commit is pushed to gitea (since some commits exist without a PR).

This way we can still cross-reference everything, share the load and assign people, without overwhelming the main repo with too much noise.

In the forgejo/governance#58 agreement, a couple of comments where concerned with the compatibility/feature-parity of forgejo with gitea if the workflow is changed from weekly-rebase to cherry-picking. They were has been addressed with the following paragraph: > 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. The weekly-rebase workflow "Furnace cleanup" has been steadily managed by @earl-warren (thank you for this!!). If the agreement is accepted, this workflow will have to change, since making a `git pull` will not simply indicate which commits of gitea have been considered or not (we may want to not apply some commits, because the issue does not concern forgejo or was addressed by another mean). Suggested solutions by @wetneb > 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 I agree that having one place to discuss every change of gitea would be very useful, since it allows to document the fate of the change (addressed in commit XXX / cherry-picked in commit YYY ...). However I think that it would make the number of PRs in forgejo too large. I would suggested instead to create a dedicated `forgejo/gitea` repo, with automation to open an *Issue* everytime a *commit* is pushed to gitea (since some commits exist without a PR). This way we can still cross-reference everything, share the load and assign people, without overwhelming the main repo with too much noise.

wetneb commented 2024年01月26日 10:59:01 +01:00

If we create issues instead of PRs, what would be the workflow to accept a Gitea change into Forgejo?
Won't that also involve creating a PR for the change?
I am not sure I see the value of having a corresponding issue in that case.

If we create issues instead of PRs, what would be the workflow to accept a Gitea change into Forgejo? Won't that also involve creating a PR for the change? I am not sure I see the value of having a corresponding issue in that case.

oliverpool commented 2024年01月26日 11:18:44 +01:00

Won't that also involve creating a PR for the change?

Yes. The issue can have copy/paste instructions so that the PR can be easily created (or a script inside contrib ./cherry-pick-gitea.sh {pr-number}):

# assuming remotes are: origin=forgejo / fork=your fork
git fetch origin # get the latest state of forgeho
git checkout -b gitea/prXXX origin/forgejo # start a dedicated branch
curl https://github.com/go-gitea/gitea/commit/534917d57670d82703567131e2b33fd945e6f8cb.patch | git am # try to apply the commit on your branch
git push fork --set-upstream

Or did you suggest that the PR should be automatically made using a script like the above? (because making a PR out of the original gitea tree will include all past commits, not just the latest one).

> Won't that also involve creating a PR for the change? Yes. The issue can have copy/paste instructions so that the PR can be easily created (or a script inside contrib `./cherry-pick-gitea.sh {pr-number}`): ```sh # assuming remotes are: origin=forgejo / fork=your fork git fetch origin # get the latest state of forgeho git checkout -b gitea/prXXX origin/forgejo # start a dedicated branch curl https://github.com/go-gitea/gitea/commit/534917d57670d82703567131e2b33fd945e6f8cb.patch | git am # try to apply the commit on your branch git push fork --set-upstream ``` Or did you suggest that the PR should be automatically made using a script like the above? (because making a PR out of the original gitea tree will include all past commits, not just the latest one).

wetneb commented 2024年01月26日 11:27:25 +01:00

Pasting those instructions only creates the branch, you then need to create the PR and wait for the CI to run. Personally, I'd be keen to have that done in the background, so I can just review the PR directly. My expectation is that we want to accept the vast majority of Gitea commits in Forgejo, at least initially. So I am not really looking forward to pasting such instructions many times a day (not necessarily myself, but as a project).

Looking at the current commit log in Gitea, they seem to have an average of 5/6 commits per day or something like that, which seems like a manageable load to me (but of course that can evolve and our own reviewing capacity can evolve too).

Pasting those instructions only creates the branch, you then need to create the PR and wait for the CI to run. Personally, I'd be keen to have that done in the background, so I can just review the PR directly. My expectation is that we want to accept the vast majority of Gitea commits in Forgejo, at least initially. So I am not really looking forward to pasting such instructions many times a day (not necessarily myself, but as a project). Looking at the current commit log in Gitea, they seem to have an average of 5/6 commits per day or something like that, which seems like a manageable load to me (but of course that can evolve and our own reviewing capacity can evolve too).

oliverpool commented 2024年01月26日 11:33:30 +01:00

You are right, it would become tedious.

Maybe an cron job could perform the steps above to cherry-pick:

• if they run successfully, a PR is automatically opened
• in case of a conflict, an issue is made, with the instruction for manually solving the conflict

With this, it would produce a mix of PR and issues directly on the forgejo/forgejo project.

You are right, it would become tedious. Maybe an cron job could perform the steps above to cherry-pick: - if they run successfully, a PR is automatically opened - in case of a conflict, an issue is made, with the instruction for manually solving the conflict With this, it would produce a mix of PR and issues directly on the `forgejo/forgejo` project.

fnetX commented 2024年01月26日 12:38:30 +01:00

Using the AGit workflow, PRs can actually be created from a script including title and description.

git push -o topic="cherry-pick-12345" -o title="GITEA: Original PR title (12345)" -o description="This is an automatic attempt to cherry-pick Gitea PR 12345. The original description follows below <br><hr>" origin HEAD:refs/for/main

---

I wondered if an alternative could work out: Merging Gitea instead of rebasing. This would make sense to me if the idea was to keep most of what upstream does for now. I expect a lot of breaking changes in the first attempt to merge this in. And I don't know how it behaves in terms of conflict resolution, I expect @dachary or @earl-warren can comment on that idea to explain why it is a bad one.

This workflow works for Codeberg's soft fork of Forgejo. We merge the release branches, sometimes add or revert commits, but the changeset is small.

Once (or if it is already the case) Forgejo does no longer want to have most of Gitea but diverge a lot, there is obviously no reason to keep merging. But until then, it might help because the rebases go away, and open PRs are no longer regularly broken, because the history becomes linear.

Using the AGit workflow, PRs can actually be created from a script including title and description. ~~~ git push -o topic="cherry-pick-12345" -o title="GITEA: Original PR title (12345)" -o description="This is an automatic attempt to cherry-pick Gitea PR 12345. The original description follows below <br><hr>" origin HEAD:refs/for/main ~~~ --- I wondered if an alternative could work out: Merging Gitea instead of rebasing. This would make sense to me if the idea was to keep *most* of what upstream does for now. I expect a lot of breaking changes in the first attempt to merge this in. And I don't know how it behaves in terms of conflict resolution, I expect @dachary or @earl-warren can comment on that idea to explain why it is a bad one. This workflow works for Codeberg's soft fork of Forgejo. We merge the release branches, sometimes add or revert commits, but the changeset is small. Once (or if it is already the case) Forgejo does no longer want to have most of Gitea but diverge a lot, there is obviously no reason to keep merging. But until then, it *might* help because the rebases go away, and open PRs are no longer regularly broken, because the history becomes linear.

fnetX commented 2024年01月26日 12:44:51 +01:00

Just adding: I believe that automatically opening PRs for every change is eventually too much noise. Having a quick glimpse at the tab will probably only show what Gitea does, not what Forgejo developers are working on.

Issues work out slightly better IMHO, because there is already more noise in the issue tab. However, I propose to do one of the following:

Regularly create a summary issue (maybe for each major version) and post PR titles and a link, maybe some stats (like diff size or labels) as comments. This acts as a quick overview. There is either a script to create a PR from an upstream title, or the PR is created as soon as there are one or two upvoting reactions. It will hep quickly skip noise of e.g. translation updates, meta work (CI and other workflow updates), and other changes that we obviously do not want to include.

Or, we create a separate repo where the changes are created as issues and proper discussion can happen. Labels could indicate to a bot (or a human) if a PR should be opened or not. It would reduce the noise here.

Just adding: I believe that automatically opening PRs for every change is eventually too much noise. Having a quick glimpse at the tab will probably only show what Gitea does, not what Forgejo developers are working on. Issues work out slightly better IMHO, because there is already more noise in the issue tab. However, I propose to do one of the following: Regularly create a summary issue (maybe for each major version) and post PR titles and a link, maybe some stats (like diff size or labels) as comments. This acts as a quick overview. There is either a script to create a PR from an upstream title, or the PR is created as soon as there are one or two upvoting reactions. It will hep quickly skip noise of e.g. translation updates, meta work (CI and other workflow updates), and other changes that we obviously do not want to include. Or, we create a separate repo where the changes are created as issues and proper discussion can happen. Labels could indicate to a bot (or a human) if a PR should be opened or not. It would reduce the noise here.

algernon commented 2024年01月26日 12:58:44 +01:00

Or, we create a separate repo where the changes are created as issues and proper discussion can happen. Labels could indicate to a bot (or a human) if a PR should be opened or not. It would reduce the noise here.

I'm liking this a lot. It allows automation, without cluttering the Forgejo issue and PR lists.

> Or, we create a separate repo where the changes are created as issues and proper discussion can happen. Labels could indicate to a bot (or a human) if a PR should be opened or not. It would reduce the noise here. I'm liking this a lot. It allows automation, without cluttering the Forgejo issue and PR lists.

earl-warren commented 2024年01月26日 13:42:45 +01:00

I also like where this is going very much and look forward to participating in making these tools /procedures when / if the hard fork happens.

I also like where this is going very much and look forward to participating in making these tools /procedures when / if the hard fork happens.

earl-warren commented 2024年03月02日 17:32:14 +01:00

For the record, the discussions about how to manage the cherry-picking post hard fork happens in the [gitea] cherry-pick pull requests. At some point it will be documented, at the moment it is progressing nicely but still in flux.

For the record, the discussions about how to manage the cherry-picking post hard fork happens in the `[gitea] cherry-pick` pull requests. At some point it will be documented, at the moment it is progressing nicely but still in flux.

fnetX commented 2025年11月10日 09:55:44 +01:00

Since no more Gitea changes are systemically integrated into Forgejo, I think this is obsolete.

Since no more Gitea changes are systemically integrated into Forgejo, I think this is obsolete.