61 lines
1.7 KiB
Markdown
61 lines
1.7 KiB
Markdown
# Future Gitea Fork Strategy
|
|
|
|
Saad's long-term intent is valid: Atay Makhzan may eventually differ enough from upstream Gitea that we maintain our own source code separately.
|
|
|
|
But the sequencing matters.
|
|
|
|
## CTO verdict
|
|
|
|
Do not fork Gitea just because we can.
|
|
|
|
Fork only when one of these is true:
|
|
|
|
1. The required feature cannot be achieved with configuration.
|
|
2. It cannot be achieved cleanly with Gitea Actions, webhooks, external automation, or themes.
|
|
3. The feature is core to Atay Makhzan's identity as a product.
|
|
4. Maintaining the patch is cheaper than working around upstream.
|
|
5. We have time to track upstream security releases and merge conflicts.
|
|
|
|
## Recommended stages
|
|
|
|
### Stage 1 — Ops sovereignty
|
|
|
|
This repository.
|
|
|
|
Goal: make deployment reproducible, documented, backed up, and safe to upgrade.
|
|
|
|
### Stage 2 — External extensions
|
|
|
|
Use webhooks, scripts, bots, custom templates, and integrations around Gitea without touching upstream source.
|
|
|
|
### Stage 3 — Theming and UX identity
|
|
|
|
Customize branding, templates, and public surfaces while remaining close to upstream.
|
|
|
|
### Stage 4 — Source fork
|
|
|
|
Create a dedicated source repository only when Atay Makhzan needs product behavior that upstream Gitea will not support.
|
|
|
|
Suggested future repo name:
|
|
|
|
```text
|
|
ibnezzoubayr/Atay-Makhzan
|
|
```
|
|
|
|
This ops repo should remain separate:
|
|
|
|
```text
|
|
ibnezzoubayr/Atay-Makhzan-Ops
|
|
```
|
|
|
|
## Fork discipline
|
|
|
|
If we fork:
|
|
|
|
- Track upstream Gitea releases.
|
|
- Keep a changelog of every divergence.
|
|
- Keep custom patches small and isolated.
|
|
- Add tests for every custom behavior.
|
|
- Maintain an upstream merge schedule.
|
|
- Never delay critical upstream security patches for cosmetic customization.
|