Hi,
On 8/15/25 20:23, Lucas Nussbaum wrote:
There is another debate below this: if Debian's workflow is different from a
standard forge workflow, does Debian need to change, or the forge?
Could it be that the standard forge workflow is optimized for
organizations with a few projects, while in many cases, Debian's
organizations (teams) deal with many projects (packages) that require an
additional layer of consistency that is difficult to standardize?
We're doing quite a few things differently than other software projects:
- the source tree for each package is an overlay file system
- Debian-specific patches are kept in a branch that is continually
rebased and seldom fully merged
- we archive imported artifacts
- packages must be self-contained and may not retrieve artifacts from
the network
None of these are handled well by existing forges, even for those where
other software projects could benefit from them. The CI system that
comes closest to declarative artifacts is SourceHut's -- the rest of the
world just writes a CMakeFile with "FetchContent" and hits the download
server every few minutes.
The overlay and the perpetually-rebased branch are somewhat related.
Neither can be inspected through the forge's web interface, and neither
has a good and consistent mapping onto git, even though git should be
predestined for that, because we are stacking multiple layers of version
control here:
- the imported source tree comes from another VCS, and
- the branch of Debian patches is itself version-controlled, because
we want to archive it for older versions of packages, we want to track
changes on it, and we want to collaborate on it.
So far, the majority of packages chooses to track changes to the changes
in git, and use tools outside of git for rebasing the branch. These
tools, again, are not available through forges.
Simon
