[DOCS] complete CONTRIBUTING.md
Signed-off-by: Loïc Dachary <loic@dachary.org>pull/54/head
Loïc Dachary
parent
8b1c304d82
commit
5908c21516
144
CONTRIBUTING.md
144
CONTRIBUTING.md
|
|
@ -1,137 +1,29 @@
|
|||
# Forgejo Contributor Guide
|
||||
|
||||
This document explains how to contribute changes to the Forgejo project.
|
||||
Sensitive security-related issues should be reported to
|
||||
[security@forgejo.org](mailto:security@forgejo.org).
|
||||
The Forgejo project is run by a community of people who are expected to follow this guide when cooperating on a simple bug fix as well as when changing the governance. For more information about the project, take a look at [the documentation explaining what Forgejo provides](README.md).
|
||||
|
||||
# Development workflow
|
||||
Sensitive security-related issues should be reported to [security@forgejo.org](mailto:security@forgejo.org) using [encryption](https://keyoxide.org/security@forgejo.org).
|
||||
|
||||
Forgejo 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 Forgejo commits are merged into a branch from which binary releases and packages are created and distributed. The development workflow is a set of conventions Forgejo developers are expected to follow to work together.
|
||||
# Table of Contents
|
||||
|
||||
## Naming conventions
|
||||
- [Code of Conduct](CONTRIBUTING/COC.md)
|
||||
- [Bugs, features and discussions](#bugs-features-and-discussions)
|
||||
- [Developer Certificate of Origin (DCO)](#developer-certificate-of-origin-dco)
|
||||
- [Development workflow](CONTRIBUTING/WORKFLOW.md)
|
||||
- [Release management](CONTRIBUTING/RELEASE.md)
|
||||
- [Governance](CONTRIBUTING/GOVERNANCE.md)
|
||||
- [Secrets](CONTRIBUTING/SECRETS.md)
|
||||
- [Security](CONTRIBUTING/SECURITY.md)
|
||||
- [Funding](CONTRIBUTING/FUNDING.md)
|
||||
|
||||
### Development
|
||||
# Bugs, features and discussions
|
||||
|
||||
* Gitea: main
|
||||
* Forgejo: forgejo
|
||||
* Integration: forgejo-integration
|
||||
* Feature branches: forgejo-feature-name
|
||||
The [Forgejo issue tracker](https://codeberg.org/forgejo/forgejo/issues) is where bugs should be reported and features requested.
|
||||
|
||||
### Stable
|
||||
Discussions regarding all non technical aspects of Forgejo, such as the governance, [happen in the **meta** issue tracker](https://codeberg.org/forgejo/meta/issues).
|
||||
|
||||
* Gitea: release/vX.Y
|
||||
* Forgejo: vX.Y/forgejo
|
||||
* Integration: vX.Y/forgejo-integration
|
||||
* Feature branches: vX.Y/forgejo-feature-name
|
||||
Other repositories in the [Forgejo organization](https://codeberg.org/forgejo) cover areas such as the [website](https://codeberg.org/forgejo/website), the [Code of Conduct](https://codeberg.org/forgejo/code-of-conduct) and more.
|
||||
|
||||
## Rebasing
|
||||
# Developer Certificate of Origin (DCO)
|
||||
|
||||
### *Feature branch*
|
||||
|
||||
The *Gitea* branches are mirrored with the Gitea development and stable branches.
|
||||
|
||||
On a regular basis, each *Feature branch* is rebased against the base *Gitea* branch.
|
||||
|
||||
### *Integration* and *Forgejo*
|
||||
|
||||
The latest *Gitea* branch resets the *Integration* branch and all *Feature branches* are merged into it.
|
||||
|
||||
If tests pass, the *Forgejo* 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* *Forgejo* branch, the CI pipeline creates and uploads binaries and packages.
|
||||
|
||||
## Feature branches
|
||||
|
||||
All *Feature branches* are based on the \*forgejo-development branch which provides and other development tools and documenation.
|
||||
|
||||
The \*forgejo-development branch is based on the \*forgejo-ci branch which provides the Woodpecker CI configuration.
|
||||
|
||||
The purpose of each *Feature branch* is documented below:
|
||||
|
||||
* [forgejo-ci](https://codeberg.org/forgejo/forgejo/src/branch/forgejo-ci) based on [main](https://codeberg.org/forgejo/forgejo/src/branch/main)
|
||||
Woodpecker CI configuration, including the release process.
|
||||
* Backports: [v1.18/forgejo-ci](https://codeberg.org/forgejo/forgejo/src/branch/v1.18/forgejo-ci)
|
||||
|
||||
* [forgejo-development](https://codeberg.org/forgejo/forgejo/src/branch/forgejo-development) based on [forgejo-ci](https://codeberg.org/forgejo/forgejo/src/branch/forgejo-ci)
|
||||
Forgejo development tools and documentation.
|
||||
* Backports: [v1.18/forgejo-development](https://codeberg.org/forgejo/forgejo/src/branch/v1.18/forgejo-development)
|
||||
|
||||
## 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
|
||||
|
||||
## Granularity
|
||||
|
||||
*Feature branches* can contain a number of commits grouped together, for instance for branding the documentation, the landing page and the footer. It makes it convenient for people working on that topic to get the big picture without browsing multiple branches. Creating a new *Feature branch* for each individual commit, while possible, is likely to be difficult to work with.
|
||||
|
||||
Observing the granularity of the existing *Feature branches* is the best way to figure out what works and what does not. It requires adjustments from time to time depending on the number of contributors and the complexity of the Forgejo codebase that sits on top of Gitea.
|
||||
|
||||
# Release management
|
||||
|
||||
## Shared user: release-team
|
||||
|
||||
The [release-team](https://codeberg.org/release-team) user authors and signs all releases. The associated email is release@forgejo.org.
|
||||
|
||||
The public GPG key used to sign the releases is [EB114F5E6C0DC2BCDD183550A4B61A2DC5923710](https://codeberg.org/release-team.gpg) `Forgejo Releases <release@forgejo.org>`
|
||||
|
||||
## Release numbering
|
||||
|
||||
The Forgejo release numbers are composed of the Gitea release number followed by a dash and a serial number. For instance:
|
||||
|
||||
* Gitea **v1.18.0** will be Forgejo **v1.18.0-0**, **v1.18.0-1**, etc
|
||||
|
||||
The Gitea release candidates are suffixed with **-rcN** which is handled as a special case for packaging: although **X.Y.Z** is lexicographically lower than **X.Y.Z-rc1** is is considered greater. The Forgejo serial number must therefore be inserted before the **-rcN** suffix to preserve the expected version ordering.
|
||||
|
||||
* Gitea **v1.18.0-rc0** will be Forgejo **v1.18.0-0-rc0**, **v1.18.0-1-rc0**
|
||||
* Gitea **v1.18.0-rc1** will be Forgejo **v1.18.0-2-rc1**, **v1.18.0-3-rc1**, **v1.18.0-4-rc1**
|
||||
* Gitea **v1.18.0** will be Forgejo **v1.18.0-5**, **v1.18.0-6**, **v1.18.0-7**
|
||||
* etc.
|
||||
|
||||
## Release process
|
||||
|
||||
* Reset the vX.Y/forgejo-integration branch to the Gitea tag vX.Y.Z
|
||||
* Merge all feature branches into the vX.Y/forgejo-integration branch
|
||||
* If the CI passes reset the vX.Y/forgejo branch to the tip of vX.Y/forgejo-integration
|
||||
* Set the vX.Y.Z-N tag to the tip of the vX.Y/forgejo branch
|
||||
* [Binaries](https://codeberg.org/forgejo/forgejo/releases) are built, signed and uploaded by the CI.
|
||||
* [Container images](https://codeberg.org/forgejo/-/packages/container/forgejo/versions) are built and uploaded by the CI.
|
||||
|
||||
## Release signing keys management
|
||||
|
||||
A GPG master key with no expiration date is created and shared with members of the Owners team via encrypted email. A subkey with a one year expiration date is created and stored in the secrets repository, to be used by the CI pipeline. The public master key is stored in the secrets repository and published where relevant.
|
||||
|
||||
### Master key creation
|
||||
|
||||
* gpg --expert --full-generate-key
|
||||
* key type: ECC and ECC option with Curve 25519 as curve
|
||||
* no expiration
|
||||
* id: Forgejo Releases <contact@forgejo.org>
|
||||
* gpg --export-secret-keys --armor EB114F5E6C0DC2BCDD183550A4B61A2DC5923710 and send via encrypted email to Owners
|
||||
* gpg --export --armor EB114F5E6C0DC2BCDD183550A4B61A2DC5923710 > release-team-gpg.pub
|
||||
* commit to the secret repository
|
||||
|
||||
### Subkey creation and renewal
|
||||
|
||||
* gpg --expert --edit-key EB114F5E6C0DC2BCDD183550A4B61A2DC5923710
|
||||
* addkey
|
||||
* key type: ECC (signature only)
|
||||
* key validity: one year
|
||||
|
||||
#### 2023
|
||||
|
||||
* gpg --export --armor F7CBF02094E7665E17ED6C44E381BF3E50D53707 > 2023-release-team-gpg.pub
|
||||
* gpg --export-secret-keys --armor F7CBF02094E7665E17ED6C44E381BF3E50D53707 > 2023-release-team-gpg
|
||||
* commit to the secret repository
|
||||
|
||||
### CI configuration
|
||||
|
||||
The `releaseteamgpg` secret in the Woodpecker CI configuration is set with the subkey.
|
||||
Contributions to Forgejo, in all the repositories in the [Forgejo organization](https://codeberg.org/forgejo) are accepted provided the author agrees to the [Developer Certificate of Origin (DCO)](CONTRIBUTING/DCO.txt).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
# Code of Conduct, Well Being and Moderation teams
|
||||
|
||||
Forgejo strives to be an inclusive project where everyone can participate in a safe environment. The [Well Being](https://codeberg.org/org/forgejo/teams/well-being) team is doing its best to defuse tensions before they escalate and is available to answer all requests sent its way. When diplomacy fails, the [Moderation](https://codeberg.org/org/forgejo/teams/moderation) will be forced to act to put a stop to actions that are contrary to the [Code of Conduct](https://codeberg.org/forgejo/code-of-conduct).
|
||||
|
||||
## Well Being and Moderation teams
|
||||
|
||||
Temporary Well Being and Moderation teams [were appointed 10 November 2022](https://codeberg.org/forgejo/meta/issues/13).
|
||||
|
||||
The moderation team will rely on this [Code of Conduct](https://codeberg.org/forgejo/code-of-conduct) when diplomacy fails.
|
||||
|
||||
### [Well Being](https://codeberg.org/org/forgejo/teams/well-being)
|
||||
|
||||
Their goal is to defuse tensions.
|
||||
|
||||
It has no power whatsover. The members are approved by the organization and trusted to:
|
||||
|
||||
- Read all communications to detect tensions between people before they escalate.
|
||||
- Do their best to defuse tensions.
|
||||
|
||||
### [Moderation](https://codeberg.org/org/forgejo/teams/moderation)
|
||||
|
||||
Their goal is to enforce the [Code of Conduct](https://codeberg.org/forgejo/code-of-conduct) when diplomacy fails.
|
||||
|
||||
It has the power to exclude people from a space.
|
||||
|
||||
Their decisions must be logical, fact based and transparent to the organization trusting them with the task.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
By making a contribution to Forgejo, I certify that:
|
||||
|
||||
(a) The contribution was created in whole or in part by me and I
|
||||
have the right to submit it under the Free Software
|
||||
indicated in the file; or
|
||||
|
||||
(b) The contribution is based upon previous work that, to the best
|
||||
of my knowledge, is covered under an appropriate Free Software
|
||||
license and I have the right under that license to submit that
|
||||
work with modifications, whether created in whole or in part
|
||||
by me, under the same Free Software license (unless I am
|
||||
permitted to submit under a different license), as indicated
|
||||
in the file; or
|
||||
|
||||
(c) The contribution was provided directly to me by some other
|
||||
person who certified (a), (b) or (c) and I have not modified
|
||||
it.
|
||||
|
||||
(d) I understand and agree that this project and the contribution
|
||||
are public and that a record of the contribution (including all
|
||||
personal information I submit with it, including my sign-off) is
|
||||
maintained indefinitely and may be redistributed consistent with
|
||||
this project or the Free Software license(s) involved.
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
# Funding per year
|
||||
|
||||
## 2022
|
||||
|
||||
* 50,000€ [to further forge federation](https://forum.forgefriends.org/t/nlnet-grant-application-for-federation-in-gitea-deadline-august-1st-2022/823)
|
||||
* 10,000€ (1,400€ October, 5,600€ November, 2,800€ December) employee delegation from Easter-eggs (Loïc Dachary)
|
||||
|
||||
# Funding ideas and prospects
|
||||
|
||||
## Grant applications
|
||||
|
||||
* [Forgejo NLnet December 1st 2022](https://codeberg.org/forgejo/funding/issues/1)
|
||||
* [UX/UI NLnet December 1st 2022](https://codeberg.org/forgejo/funding/issues/4)
|
||||
|
||||
## Discussions
|
||||
|
||||
* [Proposition](https://codeberg.org/forgejo/meta/issues/51) to log volunteers time so that it is accounted for at a 60€ per hour rate.
|
||||
* [A solution for sustaining Free Software forge development](https://blog.dachary.org/2022/11/05/a-solution-for-sustaining-forge-development/)
|
||||
* A French company delegates an employee for X month
|
||||
* The employee's time is paid for by [R&D incentive](https://fr.wikipedia.org/wiki/Cr%C3%A9dit_d%27imp%C3%B4t_recherche)
|
||||
* [Donations to Codeberg](https://codeberg.org/codename/meta/issues/26)
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
# Governance
|
||||
|
||||
## Codeberg e.V. stewards of the domains
|
||||
|
||||
The Forgejo [domains](https://codeberg.org/forgejo/meta/issues/41) are owned by the democratic non-profit dedicated to Free Software [Codeberg e.V.](https://codeberg.org/Codeberg/org/src/branch/main/en/bylaws.md). Forgejo is therefore ultimately under the control of Codeberg e.V. and its governance. However, although Codeberg e.V. is committed to use and host Forgejo, it is expected that Forgejo defines its own governance, in a way that is compatible with the Codeberg e.V. governance.
|
||||
|
||||
## Interim Forgejo Governance
|
||||
|
||||
Although Codeberg e.V. guarantees Forgejo is ultimately under the control of a trusted organization, there was a need to establish an interim Forgejo governance for safeguarding credentials, enforcing the Code of Conduct and ensuring security vulnerabilities are handled responsibly for the Forgejo releases.
|
||||
|
||||
All people with a role in the interim Forgejo governance pledge to resign as soon as the Forgejo governance is in place.
|
||||
|
||||
* [release managers](https://codeberg.org/org/forgejo/teams/releases) safeguard the keys used to sign Forgejo releases
|
||||
* [secret keepers](https://codeberg.org/org/Forgejo/teams/owners) safeguard all credentials (registrar, social accounts, etc.)
|
||||
* [security team](https://codeberg.org/org/forgejo/teams/security) handle security vulnerabilities
|
||||
* [Well Being](https://codeberg.org/org/forgejo/teams/well-being) and [Moderation](https://codeberg.org/org/forgejo/teams/moderation) teams help keep Forgejo an inclusive space
|
||||
|
||||
## Forgejo Governance
|
||||
|
||||
Forgejo was bootstraped in November 2022 and is [defining its governance](https://codeberg.org/forgejo/meta/issues/19). The [first meeting happened November 24th](https://codeberg.org/forgejo/meta/issues/19#issuecomment-694460) and was recorded. Everyone is welcome to participate in this fully transparent and cooperative process.
|
||||
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
# Release management
|
||||
|
||||
## Shared user: release-team
|
||||
|
||||
The [release-team](https://codeberg.org/release-team) user publishes and signs all releases. The associated email is mailto:release@forgejo.org.
|
||||
|
||||
The public GPG key used to sign the releases is [EB114F5E6C0DC2BCDD183550A4B61A2DC5923710](https://codeberg.org/release-team.gpg) `Forgejo Releases <release@forgejo.org>`
|
||||
|
||||
## Release numbering
|
||||
|
||||
The Forgejo release numbers are composed of the Gitea release number followed by a dash and a serial number. For instance:
|
||||
|
||||
* Gitea **v1.18.0** will be Forgejo **v1.18.0-0**, **v1.18.0-1**, etc
|
||||
|
||||
The Gitea release candidates are suffixed with **-rcN** which is handled as a special case for packaging: although **X.Y.Z** is lexicographically lower than **X.Y.Z-rc1** is is considered greater. The Forgejo serial number must therefore be inserted before the **-rcN** suffix to preserve the expected version ordering.
|
||||
|
||||
* Gitea **v1.18.0-rc0** will be Forgejo **v1.18.0-0-rc0**, **v1.18.0-1-rc0**
|
||||
* Gitea **v1.18.0-rc1** will be Forgejo **v1.18.0-2-rc1**, **v1.18.0-3-rc1**, **v1.18.0-4-rc1**
|
||||
* Gitea **v1.18.0** will be Forgejo **v1.18.0-5**, **v1.18.0-6**, **v1.18.0-7**
|
||||
* etc.
|
||||
|
||||
## Release process
|
||||
|
||||
* Reset the vX.Y/forgejo-integration branch to the Gitea tag vX.Y.Z
|
||||
* Merge all feature branches into the vX.Y/forgejo-integration branch
|
||||
* If the CI passes reset the vX.Y/forgejo branch to the tip of vX.Y/forgejo-integration
|
||||
* Set the vX.Y.Z-N tag to the tip of the vX.Y/forgejo branch
|
||||
* [Binaries](https://codeberg.org/forgejo/forgejo/releases) are built, signed and uploaded by the CI.
|
||||
* [Container images](https://codeberg.org/forgejo/-/packages/container/forgejo/versions) are built and uploaded by the CI.
|
||||
|
||||
## Release signing keys management
|
||||
|
||||
A GPG master key with no expiration date is created and shared with members of the Owners team via encrypted email. A subkey with a one year expiration date is created and stored in the secrets repository, to be used by the CI pipeline. The public master key is stored in the secrets repository and published where relevant.
|
||||
|
||||
### Master key creation
|
||||
|
||||
* gpg --expert --full-generate-key
|
||||
* key type: ECC and ECC option with Curve 25519 as curve
|
||||
* no expiration
|
||||
* id: Forgejo Releases <contact@forgejo.org>
|
||||
* gpg --export-secret-keys --armor EB114F5E6C0DC2BCDD183550A4B61A2DC5923710 and send via encrypted email to Owners
|
||||
* gpg --export --armor EB114F5E6C0DC2BCDD183550A4B61A2DC5923710 > release-team-gpg.pub
|
||||
* commit to the secret repository
|
||||
|
||||
### Subkey creation and renewal
|
||||
|
||||
* gpg --expert --edit-key EB114F5E6C0DC2BCDD183550A4B61A2DC5923710
|
||||
* addkey
|
||||
* key type: ECC (signature only)
|
||||
* key validity: one year
|
||||
* create [an issue](https://codeberg.org/forgejo/forgejo/issues) to schedule the renewal
|
||||
|
||||
#### 2023
|
||||
|
||||
* gpg --export --armor F7CBF02094E7665E17ED6C44E381BF3E50D53707 > 2023-release-team-gpg.pub
|
||||
* gpg --export-secret-keys --armor F7CBF02094E7665E17ED6C44E381BF3E50D53707 > 2023-release-team-gpg
|
||||
* commit to the secrets repository
|
||||
* renewal issue https://codeberg.org/forgejo/forgejo/issues/58
|
||||
|
||||
### CI configuration
|
||||
|
||||
The `releaseteamgpg` secret in the Woodpecker CI configuration is set with the subkey.
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
# Secrets
|
||||
|
||||
All Forgejo credentials are shared among the [secret keepers](https://codeberg.org/org/Forgejo/teams/owners) teams in a private repository with encrypted content.
|
||||
|
||||
## Get started
|
||||
|
||||
1. Make sure you have a GPG Key, or [create one](https://github.com/NicoHood/gpgit#12-key-generation)
|
||||
2. Send someone else your public key and ask this person to add yourself as a recipient
|
||||
```
|
||||
# Commands for the other person
|
||||
$ gpg --import public_key.asc
|
||||
# The following command will open a prompt, with the available public keys.
|
||||
# Choose the one you just added and all secrets will be re-encrypted with this new key.
|
||||
$ gopass recipients add
|
||||
```
|
||||
3. [Install gopass](https://www.gopass.pw/#install)
|
||||
> :warning: When installing on Ubuntu or Debian you can either download the deb package, install manually or build from source or use our APT repository ([github comment](https://github.com/gopasspw/gopass/issues/1849#issuecomment-802789285) with more information).
|
||||
4. Clone this repo using `gopass` (the name and email are for `git config`)
|
||||
```
|
||||
$ gopass clone git@codeberg.org:Forgejo/gopass.git
|
||||
```
|
||||
5. Check the consistency of the gopass storage
|
||||
```
|
||||
$ gopass fsck
|
||||
```
|
||||
|
||||
## Get a secret
|
||||
|
||||
Show the whole secret file:
|
||||
```
|
||||
$ gopass show ovh.com/manager
|
||||
```
|
||||
|
||||
Copy the password in the clipboard:
|
||||
```
|
||||
$ gopass show -c ovh.com/manager
|
||||
```
|
||||
|
||||
Copy the `user` part of the secret in the clipboard:
|
||||
```
|
||||
$ gopass show -c ovh.com/manager user
|
||||
```
|
||||
|
||||
## Insert or edit a secret
|
||||
```
|
||||
$ gopass edit ovh.com/manager
|
||||
```
|
||||
In the editor, insert the password on the first line.
|
||||
You may then add lines with a `key: value` syntax (`user: username` for instance).
|
||||
|
||||
## Debugging and manual git operations
|
||||
|
||||
The following command will show the location and status of the git repo (all git commands are available).
|
||||
```
|
||||
$ gopass git status
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# Security
|
||||
|
||||
The [security team](https://codeberg.org/org/forgejo/teams/security) handle security vulnerabilities. It handles sensitive security-related issues reported to [security@forgejo.org](mailto:security@forgejo.org) using [encryption](https://keyoxide.org/security@forgejo.org).
|
||||
|
||||
The security team also keeps the content of the [security.txt](https://codeberg.org/forgejo/website/src/branch/main/public/.well-known/security.txt) file up to date.
|
||||
|
||||
The private GPG key for `security@forgejo.org` is shared among all members of the security team and not stored online.
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
# Development workflow
|
||||
|
||||
Forgejo 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 Forgejo commits are merged into a branch from which binary releases and packages are created and distributed. The development workflow is a set of conventions Forgejo developers are expected to follow to work together.
|
||||
|
||||
Discussions on how the workflow should evolve happen [in the isssue tracker](https://codeberg.org/forgejo/forgejo/issues?type=all&state=open&labels=&milestone=0&assignee=0&q=%5BWORKFLOW%5D).
|
||||
|
||||
## Naming conventions
|
||||
|
||||
### Development
|
||||
|
||||
* Gitea: main
|
||||
* Forgejo: forgejo
|
||||
* Integration: forgejo-integration
|
||||
* Feature branches: forgejo-feature-name
|
||||
|
||||
### Stable
|
||||
|
||||
* Gitea: release/vX.Y
|
||||
* Forgejo: vX.Y/forgejo
|
||||
* Integration: vX.Y/forgejo-integration
|
||||
* Feature branches: vX.Y/forgejo-feature-name
|
||||
|
||||
## Rebasing
|
||||
|
||||
### *Feature branch*
|
||||
|
||||
The *Gitea* branches are mirrored with the Gitea development and stable branches.
|
||||
|
||||
On a regular basis, each *Feature branch* is rebased against the base *Gitea* branch.
|
||||
|
||||
### *Integration* and *Forgejo*
|
||||
|
||||
The latest *Gitea* branch resets the *Integration* branch and all *Feature branches* are merged into it.
|
||||
|
||||
If tests pass, the *Forgejo* 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* *Forgejo* branch, the CI pipeline creates and uploads binaries and packages.
|
||||
|
||||
## Feature branches
|
||||
|
||||
All *Feature branches* are based on the {vX.Y/,}forgejo-development branch which provides and other development tools and documenation.
|
||||
|
||||
The \*forgejo-development branch is based on the {vX.Y/,}forgejo-ci branch which provides the Woodpecker CI configuration.
|
||||
|
||||
The purpose of each *Feature branch* is documented below:
|
||||
|
||||
* [forgejo-ci](https://codeberg.org/forgejo/forgejo/src/branch/forgejo-ci) based on [main](https://codeberg.org/forgejo/forgejo/src/branch/main)
|
||||
Woodpecker CI configuration, including the release process.
|
||||
* Backports: [v1.18/forgejo-ci](https://codeberg.org/forgejo/forgejo/src/branch/v1.18/forgejo-ci)
|
||||
|
||||
* [forgejo-development](https://codeberg.org/forgejo/forgejo/src/branch/forgejo-development) based on [forgejo-ci](https://codeberg.org/forgejo/forgejo/src/branch/forgejo-ci)
|
||||
Forgejo development tools and documentation.
|
||||
* Backports: [v1.18/forgejo-development](https://codeberg.org/forgejo/forgejo/src/branch/v1.18/forgejo-development)
|
||||
|
||||
## Pull requests and feature branches
|
||||
|
||||
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*.
|
||||
|
||||
## Granularity
|
||||
|
||||
*Feature branches* can contain a number of commits grouped together, for instance for branding the documentation, the landing page and the footer. It makes it convenient for people working on that topic to get the big picture without browsing multiple branches. Creating a new *Feature branch* for each individual commit, while possible, is likely to be difficult to work with.
|
||||
|
||||
Observing the granularity of the existing *Feature branches* is the best way to figure out what works and what does not. It requires adjustments from time to time depending on the number of contributors and the complexity of the Forgejo codebase that sits on top of Gitea.
|
||||
29
README.md
29
README.md
|
|
@ -38,32 +38,9 @@ If you like any of the following, Forgejo is literally meant for you:
|
|||
## Learn more
|
||||
|
||||
We're still working on our website.
|
||||
In the meantime, you can <a href="https://floss.social/@forgejo" rel="me">find us on the Fediverse</a> or hop into [our Matrix room](https://matrix.to/#/#forgejo-chat:matrix.org) if you have any questions or want to get involved.
|
||||
In the meantime, you can <a href="https://floss.social/@Forgejo" rel="me">find us on the Fediverse</a> or hop into [our Matrix room](https://matrix.to/#/#Forgejo-chat:matrix.org) if you have any questions or want to get involved.
|
||||
|
||||
|
||||
## Getting started
|
||||
## Get involved
|
||||
|
||||
We're working towards our first release.
|
||||
The download options will be published here.
|
||||
|
||||
### Documentation
|
||||
|
||||
...
|
||||
|
||||
## Roadmap
|
||||
|
||||
We're currently working on ... for the next release.
|
||||
|
||||
|
||||
### Status of Federation
|
||||
|
||||
...
|
||||
|
||||
|
||||
## Contributing
|
||||
|
||||
...
|
||||
|
||||
### Translating
|
||||
|
||||
## Thanks to ...
|
||||
If you are interested in making Forgejo better, either by reporting a bug or by changing the governance, please [take a look at the contribution guide](CONTRIBUTING.md).
|
||||
|
|
|
|||
Loading…
Reference in New Issue