Proposal: Switch to linear git history
Hi folks
The repository for the Linux kernel in Debian currently makes heavy use
of merges, which will always conflict due to changelog changes. This
constitutes high cognitive busy load, for pretty small gains.
After already removing the manually modified abiname, we can drop more
manual work with that. As the now requires operarions will not longer
produce conflicts, we can easily create tools if we want.
What did I miss?
## Current state
The linux repo uses a kind of classic Debian like branch setup:
- master: for development work, uploaded to experimental
- sid: uploaded to sid
- bookworm
- bookworm-backports
- bookworm-security
Between different branches a lot of merges happen. Between master and
sid in both directions, so changes can be done in both places and
changelogs show a linear history. Between sid and *-backports.
Those merges are done by hand. In many cases conflict with each other
due to mainly changelog changes, which needs to cleaned up by hand.
## Proposal
Stop merging back changes, but create version distinct branches.
Something like that:
master: uploaded to experimental
-> debian/main/6.6: uploaded to unstable and stable releases
-> debian/backport/6.6.1-1: uploaded to backports
-> debian/security/6.6.1+1: extra security releases
## Disadvantages
- All changes need to go via master, which they should do anyway.
- In case of patch backports:
- A bug will be closed multiple times.
- The exact version a change reached unstable is not longer visible.
- No automatic way for patches required in the backports suites (I have
a larger config overhaul, where we could add something for that.)
--
The heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
Reply to: