# 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.