dachary commented

Member

Draft documentation of the development workflow in the pad for collaborative editing https://pad.gusted.xyz/Rs70GWB6SWi27B44tBCpKA?view

The development workflow of a soft fork means maintaining a set of patches that are to be applied to the development and stable branches of Gitea over a long period of time because (for whatever reason) they are not going to be merged in Gitea.

This is a well established practice in the Free Software world:

Debian developers create packages out of sources with bug fixes and additions, helped by tooling developed over the years, capable of juggling with hundreds of patches.
Thousands of companies work on the Linux kernel with no interaction whatsoever with the upstream kernel developers, although they could.
Android forks like LineageOS or proprietary derivatives from Samsung or Xiaomi are obliged to work in this way because the codebase is developped in secret by Google and released once a year.

It must be done a sane way, to keep the technical debt associated with it in check at all times.

Codeberg fork development workflow

The development workflow in place at https://codeberg.org/codeberg/gitea works fine for now but has a significant drawback. The content of the patch is split between the patch itself and the conflict resolution that happens when merging the upstream branch. Whatever workflow is decided must avoid that pitfall.

forgefriends fork development workflow

The development workflow in place at forgefriends https://forum.forgefriends.org/t/cheatlist-for-forgefriends-development/429 has worked well in the past year with weekly rebasing. It resembles what Linux kernel developpers do which essentially boils down to:

implementing something in a feature branch based on dev / stable
rebasing the feature branch, chasing dev / stable and resolving conflicts to keep the commit history clean
merging all feature branches into an integration branch for the purpose of testing if they fit well with each other
producing a release out of the integration branch

Draft documentation of the development workflow in the pad for collaborative editing https://pad.gusted.xyz/Rs70GWB6SWi27B44tBCpKA?view --- The development workflow of a soft fork means maintaining a set of patches that are to be applied to the development and stable branches of Gitea over a long period of time because (for whatever reason) they are not going to be merged in Gitea. This is a well established practice in the Free Software world: * Debian developers create packages out of sources with bug fixes and additions, helped by tooling developed over the years, capable of juggling with hundreds of patches. * Thousands of companies work on the Linux kernel with no interaction whatsoever with the upstream kernel developers, although they could. * Android forks like LineageOS or proprietary derivatives from Samsung or Xiaomi are obliged to work in this way because the codebase is developped in secret by Google and released once a year. It must be done a sane way, to keep the technical debt associated with it in check at all times. ### Codeberg fork development workflow The development workflow in place at https://codeberg.org/codeberg/gitea works fine for now but has a significant drawback. The content of the patch is split between the patch itself and the conflict resolution that happens when merging the upstream branch. Whatever workflow is decided must avoid that pitfall. ### forgefriends fork development workflow The development workflow in place at forgefriends https://forum.forgefriends.org/t/cheatlist-for-forgefriends-development/429 has worked well in the past year with weekly rebasing. It resembles what Linux kernel developpers do which essentially boils down to: - implementing something in a feature branch based on dev / stable - rebasing the feature branch, chasing dev / stable and resolving conflicts to keep the commit history clean - merging all feature branches into an integration branch for the purpose of testing if they fit well with each other - producing a release out of the integration branch

dachary added this to the Launch milestone 2022-11-08 11:54:38 +00:00

dachary self-assigned this 2022-11-08 11:54:38 +00:00

dachary referenced this issue from forgejo/meta

2022-11-08 11:55:13 +00:00

[moved] Document the development workflow of the fork #22

dachary commented

2022-11-08 11:55:53 +00:00

Author

Member

This issue was moved from codename/meta#22

This issue was moved from https://codeberg.org/codename/meta/issues/22

dachary referenced this issue

2022-11-09 10:07:27 +00:00

Replace Readme & Contributing #7

dachary commented

2022-11-09 10:09:24 +00:00

Author

Member

For the record, a related discussion happened here codename/codename#7 (comment)

For the record, a related discussion happened here https://codeberg.org/codename/codename/issues/7#issuecomment-669099

dachary commented

2022-11-09 10:19:39 +00:00

Author

Member

@codename/Owners My preferred development workflow for "codename" is to have feature branches where changes are maintained, rebased on Gitea main for development and rebased on Gitea stable branches for backports. It is similar to what kernel developers do when they do not work mainline and it is what was chosen for forgefriends.

The feature branches are merged together in an integration branch for testing. If the tests pass, the "codename" branch is reset hard to the tip of the integration branch. Releases are created by setting tags on the tip of the "codename" branch. Nothing is ever merged in the "codename" branch.

I'll document that in detail if there is a consensus to go in this direction.

@codename/Owners My preferred development workflow for "codename" is to have feature branches where changes are maintained, rebased on Gitea main for development and rebased on Gitea stable branches for backports. It is similar to what kernel developers do when they do not work mainline and it is what was [chosen for forgefriends](https://forum.forgefriends.org/t/cheatlist-for-forgefriends-development/429). The feature branches are merged together in an integration branch for testing. If the tests pass, the "codename" branch is reset hard to the tip of the integration branch. Releases are created by setting tags on the tip of the "codename" branch. Nothing is ever merged in the "codename" branch. I'll document that in detail if there is a consensus to go in this direction.

👍 1

Gusted commented

2022-11-09 18:54:01 +00:00

Owner

I never used feature branches, but happy to experiment with it. LGTM.

Ryuno-Ki commented

2022-11-09 20:43:08 +00:00

@Gusted Do you need some general introduction material? (With charts and everything)

@dachary If we go with feature branches, will this be kind of git flow or something different?

@Gusted Do you need some general introduction material? (With charts and everything) @dachary If we go with feature branches, will this be kind of `git flow` or something different?

Gusted commented

2022-11-09 23:06:40 +00:00

Owner

Do you need some general introduction material? (With charts and everything)

Nah, not really. I can likely pick up the flow, but we might need those for those that are less experienced with Git/workflows.

> Do you need some general introduction material? (With charts and everything) Nah, not really. I can likely pick up the flow, but we might need those for those that are less experienced with Git/workflows.

fnetX commented

2022-11-09 23:57:48 +00:00

Owner

Hi all,

watching here and thinking hard about what I'd prefer. The basic outcome is: Let's be flexible, see what works for us, and easily propose and communicate changes.

A first requirement everyone can accept, is that development branches are rebased and force-pushed. This might and will lead to confusion, e.g. if a newly opened PR targets the main branch, but we just rebased our state, and now the base for the PR is gone. We could also consider using a schedule, e.g. rebase three times a week on fixed dates, and otherwise merge if possible.

What we should always avoid is doing conflict resolution during merge, because this means that we will have to resolve a conflict twice or fiddle deeply with Git (and from my experience, not everyone is into this).

So far, my proposal works like this:

downstream commits are prefixed with CN/type: (Codename/type: e.g. CN/bp: for backports, CN/tmpl: just cosmetic changes, CN/feat: for real features - let's sync to the terminology of the Codeberg fork (which is in my head only, I guess, let's change this))
stable branches are merged as we see fit, and as soon as a merge conflict happens, all downstream commits are rebased and the branch is force-pushed (e.g. codename-1.18 etc)
main branches are merged as we see fit (or using a schedule), and as soon as a merge conflict happens, all downstream commits are rebased. We could make use of a script to update all PRs along.
before force-pushing, we ensure that every PR that can be merged, is already merged (especially backports): Less conflict blocking of PRs

Hi all, watching here and thinking hard about what I'd prefer. The basic outcome is: Let's be flexible, see what works for us, and easily propose and communicate changes. A first requirement everyone can accept, is that development branches are rebased and **force-pushed**. This might and will lead to confusion, e.g. if a newly opened PR targets the main branch, but we just rebased our state, and now the base for the PR is gone. We could also consider using a schedule, e.g. rebase three times a week on fixed dates, and otherwise merge *if possible*. What we should always avoid is doing conflict resolution during merge, because this means that we will have to resolve a conflict twice or fiddle deeply with Git (and from my experience, not everyone is into this). So far, my proposal works like this: - downstream commits are prefixed with CN/type: (Codename/type: e.g. CN/bp: for backports, CN/tmpl: just cosmetic changes, CN/feat: for real features - let's sync to the terminology of the Codeberg fork (which is in my head only, I guess, let's change this)) - stable branches are merged as we see fit, and as soon as a merge conflict happens, all downstream commits are rebased and the branch is force-pushed (e.g. codename-1.18 etc) - main branches are merged as we see fit (or using a schedule), and as soon as a merge conflict happens, all downstream commits are rebased. We could make use of a script to update all PRs along. - before force-pushing, we ensure that every PR that can be merged, is already merged (especially backports): Less conflict blocking of PRs

dachary commented

2022-11-10 01:32:36 +00:00

Author

Member

Would that work for you if CN/type were branches instead of commits? One branch per commit (and maybe group some of them in the same branch if that makes more sense). Working on one commit is more challenging than working on a branch. A branch allows for:

pull requests
series of commits instead of a single large commit
isolation when rebasing and resolving conflicts, multiple people are able to work in parallel on different branches

Would that work for you if CN/type were branches instead of commits? One branch per commit (and maybe group some of them in the same branch if that makes more sense). Working on one commit is more challenging than working on a branch. A branch allows for: * pull requests * series of commits instead of a single large commit * isolation when rebasing and resolving conflicts, multiple people are able to work in parallel on different branches

👍 2

caesar commented

2022-11-10 02:23:02 +00:00

Member

@dachary 's original proposal makes sense to me on a superficial reading, @fnetX 's proposal I find harder to follow. But I have no experience working with a soft fork like this where patches have to be kept up to date, so I'll let the two of you who do have that experience work it out!

I think very clear documentation will be vital if we want contributions from folks who aren't Git workflow experts. Eg, what branch should someone send PRs against? Etc. Ideally it should be as easy to contribute as just sending a PR to the main branch of any other project. The more the complicated workflow can be "hidden" the better.

I wonder if there's anything to learn from Electron, who effectively maintain a very complicated soft fork of Chromium...

@dachary 's original proposal makes sense to me on a superficial reading, @fnetX 's proposal I find harder to follow. But I have no experience working with a soft fork like this where patches have to be kept up to date, so I'll let the two of you who do have that experience work it out! I think very clear documentation will be vital if we want contributions from folks who aren't Git workflow experts. Eg, what branch should someone send PRs against? Etc. Ideally it should be as easy to contribute as just sending a PR to the `main` branch of any other project. The more the complicated workflow can be "hidden" the better. I wonder if there's anything to learn from Electron, who effectively maintain a *very* complicated soft fork of Chromium...

fnetX commented

2022-11-10 09:04:24 +00:00

Owner

@dachary we can try this with branches. I only now understand your proposal with all the implications. I think I'd find it more confusing to handle all the branches, because a simple "rebase" takes care of all the commits, and with branches it might be harder to remember in which order the commits were applied, or which commits to apply at all. But let's try.

👍 1

dachary commented

2022-11-10 09:27:20 +00:00

Author

Member

I'll document the "feature branch" workflow then.

It is indeed less straightforward than to rebase a list of patches, that's one drawback, I won't pretend otherwise. But I believe that overall the "pros" outweigh the "cons".

I'll document the "feature branch" workflow then. It is indeed less straightforward than to rebase a list of patches, that's one drawback, I won't pretend otherwise. But I believe that overall the "pros" outweigh the "cons".

caesar referenced this issue

2022-11-10 09:38:39 +00:00

Replace Readme & Contributing #7

caesar commented

2022-11-10 09:41:58 +00:00

Member

I assume you will update CONTRIBUTING.md accordingly, @dachary?

Another consideration, how will we handle translations? (Perhaps that's for a separate issue…)

I assume you will update `CONTRIBUTING.md` accordingly, @dachary? Another consideration, how will we handle translations? (Perhaps that's for a separate issue…)

dachary commented

2022-11-10 09:46:31 +00:00

Author

Member

I assume you will update CONTRIBUTING.md accordingly, @dachary?

Yes.

Another consideration, how will we handle translations? (Perhaps that's for a separate issue…)

That's a very difficult topic unfortunately. Realistically I don't see how to participate in the translations in any way as the process in place is bound to crowdin. But indeed, that's worth a different issue :-)

> I assume you will update `CONTRIBUTING.md` accordingly, @dachary? Yes. > Another consideration, how will we handle translations? (Perhaps that's for a separate issue…) That's a very difficult topic unfortunately. Realistically I don't see how to participate in the translations in any way as the process in place is bound to crowdin. But indeed, that's worth a different issue :-)

👍 1

fnetX commented

2022-11-10 09:57:03 +00:00

Owner

If we introduce new strings, we could add them using a prefix for now. Not optimal long-term, but works for now.

I'm actually planning to do this for Codeberg using a separate file and patching our build script to merge them, because all Codeberg-specific templates are currently untranslated.

We could then add such file(s) to the Codeberg Weblate Instance.

If we introduce new strings, we could add them using a prefix for now. Not optimal long-term, but works for now. I'm actually planning to do this for Codeberg using a separate file and patching our build script to merge them, because all Codeberg-specific templates are currently untranslated. We could then add such file(s) to the [Codeberg Weblate Instance](https://translate.codeberg.org).

👍 2

~~caesar referenced this issue 2022-11-10 10:16:36 +00:00~~

[WORKFLOW] translations #8

caesar referenced this issue

2022-11-10 10:25:16 +00:00

Replace the issue templates #9

caesar added a new dependency 2022-11-10 10:25:50 +00:00

#9 Replace the issue templates

dachary commented

2022-11-11 09:00:41 +00:00

Author

Member

Starting a pad to document the workflow https://pad.gusted.xyz/Rs70GWB6SWi27B44tBCpKA#

dachary commented

2022-11-11 09:58:48 +00:00

Author

Member

Here is a first draft. What do you think?

Codename is a soft fork, i.e. a set of commits applied to the Gitea development branch and the stable branches. On a regular basis those commits are rebased and modified if necessary to keep working. All Codename commits are merged into a branch from which binary releases and packages are created and distributed. The development workflow is a set of conventions Codename developers are expected to follow to work together.

Naming conventions

Development

Gitea: main
Codename: codename
Integration: codename-integration
Feature branches: codename-feature-name

Stable

Gitea: release/vX.Y
Codename: vX.Y/codename
Integration: vX.Y/codename-integration
Feature branches: vX.Y/codename-feature-name

Rebasing

The latest Gitea branch resets the Integration branch and all Feature branches are merged into it.

If tests pass, the Codename branch is reset to the tip of the Integration branch.

If tests do not pass, an issue is filed to the Feature branch that fails the test. Once the issue is resolved, another round of rebasing starts.

Releasing

When a tag is set to a Stable Codename branch, the CI pipeline creates and uploads binaries and packages.

Feature branches

All Feature branches are based on the *codename-development branch which provides the Woodpecker CI configuration and other development tools.

Here is a first draft. What do you think? --- Codename is a soft fork, i.e. a set of commits applied to the Gitea development branch and the stable branches. On a regular basis those commits are rebased and modified if necessary to keep working. All Codename commits are merged into a branch from which binary releases and packages are created and distributed. The development workflow is a set of conventions Codename developers are expected to follow to work together. # Naming conventions ## Development * Gitea: main * Codename: codename * Integration: codename-integration * Feature branches: codename-feature-name ## Stable * Gitea: release/vX.Y * Codename: vX.Y/codename * Integration: vX.Y/codename-integration * Feature branches: vX.Y/codename-feature-name # Rebasing The latest *Gitea* branch resets the *Integration* branch and all *Feature branches* are merged into it. If tests pass, the *Codename* branch is reset to the tip of the *Integration* branch. If tests do not pass, an issue is filed to the *Feature branch* that fails the test. Once the issue is resolved, another round of rebasing starts. # Releasing When a tag is set to a *Stable* *Codename* branch, the CI pipeline creates and uploads binaries and packages. # Feature branches All *Feature branches* are based on the \*codename-development branch which provides the Woodpecker CI configuration and other development tools.

caesar commented

2022-11-11 10:09:52 +00:00

Member

I think it could do with a simple overview of how a new contributor should work. It needs to answer at least the following questions:

Which branch do I work from?
Which branch do I send PRs against?

For example, most people who are used to contributing to open-source code will be familiar with the workflow of sending a PR against the repo's default branch.
In the case of contributing to Codename, they need to know what's different compared to that familiar workflow.

I think it could do with a simple overview of how a new contributor should work. It needs to answer at least the following questions: - Which branch do I work from? - Which branch do I send PRs against? For example, most people who are used to contributing to open-source code will be familiar with the workflow of sending a PR against the repo's default branch. In the case of contributing to Codename, they need to know what's different compared to that familiar workflow.

👍 3

caesar referenced this issue

2022-11-11 10:23:16 +00:00

Replace the issue templates #9

dachary commented

2022-11-11 12:34:36 +00:00

Author

Member

Very good point, the draft was modified and now ends with:

Feature branches

All Feature branches are based on the *codename-development branch which provides the Woodpecker CI configuration and other development tools.

The purpose of each Feature branch is documented in CONTRIBUTING.md as follows:

Name of the Feature branch and name of the base Feature branch (for instance codename-federation based on codename-development)
- Backports: list of the versions in which this Feature branch is supported (for instance v1.18, v1.19)
- Description: explains what the focus of the Feature branch is (for instance: forge federation features)

Contributing

Most people who are used to contributing will be familiar with the workflow of sending a pull request against the default branch. When that happens the reviewer should change the base branch to the appropriate Feature branch instead. If the pull request does not fit in any Feature branch, the reviewer needs to make decision to either:

Decline the pull request because it is best contributed to Gitea
Create a new Feature branch

Returning contributors can figure out which Feature branch to base their pull request on using the list of Feature branches found in CONTRIBUTING.md

Very good point, the [draft was modified](https://pad.gusted.xyz/Rs70GWB6SWi27B44tBCpKA?edit) and now ends with: --- # Feature branches All *Feature branches* are based on the \*codename-development branch which provides the Woodpecker CI configuration and other development tools. The purpose of each *Feature branch* is documented in CONTRIBUTING.md as follows: * Name of the *Feature branch* and name of the base *Feature branch* (for instance codename-federation based on codename-development) * Backports: list of the versions in which this *Feature branch* is supported (for instance v1.18, v1.19) * Description: explains what the focus of the *Feature branch* is (for instance: forge federation features) # Contributing Most people who are used to contributing will be familiar with the workflow of sending a pull request against the default branch. When that happens the reviewer should change the base branch to the appropriate *Feature branch* instead. If the pull request does not fit in any *Feature branch*, the reviewer needs to make decision to either: * Decline the pull request because it is best contributed to Gitea * Create a new *Feature branch* Returning contributors can figure out which *Feature branch* to base their pull request on using the list of *Feature branches* found in CONTRIBUTING.md

Ryuno-Ki commented

2022-11-11 14:02:00 +00:00

downstream commits are prefixed with CN/type: (Codename/type: e.g. CN/bp: for backports, CN/tmpl: just cosmetic changes, CN/feat: for real features - let's sync to the terminology of the Codeberg fork (which is in my head only, I guess, let's change this))

Node.js world has commitlint to validate this.

before force-pushing, we ensure that every PR that can be merged, is already merged (especially backports): Less conflict blocking of PRs

This could lead to a lock state.

> - downstream commits are prefixed with CN/type: (Codename/type: e.g. CN/bp: for backports, CN/tmpl: just cosmetic changes, CN/feat: for real features - let's sync to the terminology of the Codeberg fork (which is in my head only, I guess, let's change this)) Node.js world has [commitlint](https://commitlint.js.org/#/) to validate this. > - before force-pushing, we ensure that every PR that can be merged, is already merged (especially backports): Less conflict blocking of PRs This could lead to a lock state.

Ryuno-Ki commented

2022-11-11 14:05:35 +00:00

If tests do not pass, an issue is filed to the Feature branch that fails the test. Once the issue is resolved, another round of rebasing starts.

What if multiple feature branches fail? When will the round start? As soon as the first one is resolved? Waiting for all of them?

> If tests do not pass, an issue is filed to the *Feature branch* that fails the test. Once the issue is resolved, another round of rebasing starts. What if multiple feature branches fail? When will the round start? As soon as the first one is resolved? Waiting for all of them?

dachary commented

2022-11-12 00:52:16 +00:00

Author

Member

It's worth starting a new round each time a feature branch is fixed, IMHO.

caesar commented

2022-11-12 06:24:39 +00:00

Member

So just to clarify: an external contributor sending a PR for a new feature should send it against the default branch, and whoever reviews it will create a branch for it?

dachary commented

2022-11-12 08:15:05 +00:00

Author

Member

Yes, in the most complicated case where an external contributor:

proposes a patch that is in scope for the soft-fork
does so by creating a pull request against the default branch
the patch does not fit in any of the existing feature branches

A more likely scenario, IMHO, is when an external contributor:

proposes a patch that is in scope for the soft-fork
does so by creating a pull request against the default branch
the patch fits in an existing feature branch

The reviewer would then just ask the external contributor to change the base branch like below or do it themselves.

Does that sound reasonable?

Yes, in the most complicated case where an external contributor: * proposes a patch that is in scope for the soft-fork * does so by creating a pull request against the default branch * **the patch does not fit** in any of the existing feature branches A more likely scenario, IMHO, is when an external contributor: * proposes a patch that is in scope for the soft-fork * does so by creating a pull request against the default branch * **the patch fits** in an existing feature branch The reviewer would then just ask the external contributor to change the base branch like below or do it themselves. ![image](/attachments/e36eea80-b533-4f1f-b1c1-aec64d00f43a) Does that sound reasonable?

image.png

74 KiB

caesar commented

2022-11-12 09:12:10 +00:00

Member

Yes, that makes sense to me - I think the granularity of the "feature branches" is probably coarser than I had initially imagined, which will make it easier to keep them up to date.

dachary commented

2022-11-12 09:28:16 +00:00

Author

Member

The granularity of the branches is indeed of significant importance to keep the friction minimum and the features isolated. A single feature branch grouping all commits related to branding Codename would make sense to me and allow people to focus on that topic. If it is split into multiple branches, one dealing with s/Gitea/Codename/ and another dealing with the web UI, that may also make sense but probably require more coordination and increase the chances of conflicts when merging. Creating a new branch for each commit is likely to be too fine grain, very cumbersome and confusing.

I don't think it is possible to write down a policy that explains how to keep that balance, it's a mix of common sense and dialog among developers. I also think that once there are a few branches in place and a few weekly merge happened, it will become clearer.

The granularity of the branches is indeed of significant importance to keep the friction minimum and the features isolated. A single feature branch grouping all commits related to branding Codename would make sense to me and allow people to focus on that topic. If it is split into multiple branches, one dealing with s/Gitea/Codename/ and another dealing with the web UI, that may also make sense but probably require more coordination and increase the chances of conflicts when merging. Creating a new branch for each commit is likely to be too fine grain, very cumbersome and confusing. I don't think it is possible to write down a policy that explains how to keep that balance, it's a mix of common sense and dialog among developers. I also think that once there are a few branches in place and a few weekly merge happened, it will become clearer.

👍 2

Ryuno-Ki commented

2022-11-12 11:22:59 +00:00

If this discussion settles down for a bit and a consensus emerges I would be happy to create a decision diagram using mermaid and PR the CONTRIBUTION.md file.

If this discussion settles down for a bit and a consensus emerges I would be happy to create a decision diagram using [mermaid](https://mermaid-js.github.io/mermaid-live-editor/) and PR the CONTRIBUTION.md file.

❤️ 1

dachary commented

2022-11-12 13:24:27 +00:00

Author

Member

I added a section about the granularity of branches to the workflow documentation

https://pad.gusted.xyz/Rs70GWB6SWi27B44tBCpKA?view#Granularity

it probably is going to come up a few times.

I added a section about the granularity of branches to the workflow documentation https://pad.gusted.xyz/Rs70GWB6SWi27B44tBCpKA?view#Granularity it probably is going to come up a few times.

👍 1

dachary commented

2022-11-14 13:54:45 +00:00

Author

Member

Updated the pad https://pad.gusted.xyz/Rs70GWB6SWi27B44tBCpKA to reword the part about rebasing. While explaining it during the forgefriends coworking session (recording will be available today), I realized it was missing a bit of information.

Updated the pad https://pad.gusted.xyz/Rs70GWB6SWi27B44tBCpKA to reword the part about rebasing. While explaining it during the [forgefriends coworking session](https://forum.forgefriends.org/t/forgefriends-online-coworking-november-14th-2pm-utc-1/950) (recording will be available today), I realized it was missing a bit of information.

👍 2

dachary referenced this issue from a commit

2022-11-15 16:52:28 +00:00

Codename development workflow

~~dachary referenced this issue 2022-11-15 17:07:23 +00:00~~

Bootstrap the development workflow #12

dachary closed this issue

2022-11-15 17:08:25 +00:00

dachary commented

2022-11-15 17:12:04 +00:00

Author

Member

It is now in https://codeberg.org/codename/codename/src/branch/codename/WORKFLOW.md

I opened codename/codename#12 to discuss the details of bootstraping the development workflow. It's far from perfect but we can improve on it.

It is now in https://codeberg.org/codename/codename/src/branch/codename/WORKFLOW.md I opened https://codeberg.org/codename/codename/issues/12 to discuss the details of bootstraping the development workflow. It's far from perfect but we can improve on it.

dachary referenced this issue from a commit

2022-11-16 12:08:32 +00:00

Forgejo development workflow

caesar referenced this issue from forgejo/meta

2022-11-20 11:10:41 +00:00

[moved] Document the development workflow of the fork #22

dachary referenced this issue from a commit

2022-11-25 23:18:52 +00:00

Forgejo development workflow