# Red Bear OS Source Ownership Model

**Effective:** 2026-06 (migrated from patch-based build system)
**Replaces:** PATCH-GOVERNANCE.md, AGENTS.md patch sections

## What Changed

Red Bear OS migrated from a patch-based build system to direct source ownership.
Previously, we maintained upstream Redox source + 341 patch files applied at build
time. Now, we maintain our own git forks of every component under `local/sources/`.

The source IS the source. No patches. No indirection. Edit, build, commit.

## Where Source Lives

| Component | Fork Location |
|---|---|
| Kernel | `local/sources/kernel/` |
| C library (relibc) | `local/sources/relibc/` |
| Userspace drivers (base) | `local/sources/base/` |
| Bootloader | `local/sources/bootloader/` |
| Installer | `local/sources/installer/` |
| RedoxFS | `local/sources/redoxfs/` |
| User utilities | `local/sources/userutils/` |

Additional components have individual forks as needed. Each fork is a git
repository initialized from the frozen Redox 0.1.0 baseline with all Red Bear
modifications applied as the initial commit.

## Daily Workflow

### Make a change
```bash
vim local/sources/relibc/src/header/sys_signalfd/mod.rs
./target/release/repo cook relibc
make qemu CONFIG_NAME=redbear-mini
git -C local/sources/relibc commit -m "relibc: fix signalfd edge case"
```

### Integrate upstream improvements
Upstream Redox is a reference. When they improve something you want:

```bash
cd local/sources/relibc
git remote add upstream https://gitlab.redox-os.org/redox-os/relibc.git
git fetch upstream
git log upstream/main --not main --oneline
# Read each interesting commit. Understand it. Port manually.
git commit -m "relibc: port upstream fix (ref: redox <sha>)"
```

### Release
Tag each component repo with the release version:
```bash
git -C local/sources/kernel tag v0.2.3
git -C local/sources/relibc tag v0.2.3
git -C local/sources/base tag v0.2.3
# Build from tags
```

## Why This Is Better

| Before (Patches) | After (Source Ownership) |
|---|---|
| 341 .patch files to manage | 0 patches. History in git. |
| 5-step edit cycle (edit → diff → save → wire → validate → build) | 2-step (edit → build) |
| New developers must learn patch system | Standard git workflow |
| make clean could destroy unpatched work | Work lives in git repos |
| Mega-patch corruption and hunk failures | Git merge conflicts (standard, tool-supported) |
| ~5,000 words of patch documentation | ~300 words of source model documentation |

## Historical Note

The old patch files in `local/patches/` are preserved as historical reference.
Each patch was converted into the initial commit of its corresponding fork repo.
To trace a change: `git log local/sources/base/` — commit messages reference the
original patch filenames.

## Recipe Configuration

Recipes that use Red Bear forks configure their source as a local path:

```toml
[source]
path = "../../../local/sources/base"
```

Recipes for non-forked packages (upstream libraries, tools) use standard git
or tar sources without patches — the source is fetched directly.