Re: Proposal: Switch to linear git history
Hi
On Sun, Jan 14, 2024 at 09:07:07PM +0100, Salvatore Bonaccorso wrote:
> How would in the new scheme typical workflow look like? Maybe this
> could help better understand the proposed changes. As you know in my
> focus is mainly working on the stable branches, be it to rebase to
> more recent stable upstream version, then targetting in either point
> releases or security uploads, but as well picking single needing fixes
> (for instance targetted security fixes).
Adding patches to all:
- Via merge request to master
- Can be cherry picked to other release branches down the chain
unstable, stable, security as necessary
Adding patches only required for release:
- Via merge request to debian/release/6.6
- Can be cherry picked further down the same way
Adding new upstream releases for unstable, stable:
- Import new upstream release into debian/release/6.6
Adding new upstream releases for security or even go back from current
state of release branch (this is an emergency procedure):
- Create debian/security/6.6.9 from the nearest tag
- Import new upstream release
Targeted fixes for security:
- Create debian/security/6.6.9 from debian/6.6.9-1 tag
- Choose new version (6.6.9+1-1)
- Add patches. We can also try the GitLab feature for private merge
requests then
Uploads to backports:
- Create debian/backport/6.6.9-1+deb13u1 from debian/6.6.9-1+deb13u1 tag
- Choose new version (6.6.9-1+deb13u1~bpo12+1)
- (For now: change things like compiler)
- Release from there
In the end creating branches on releases needs the operator to find a
suitable ancestor, which might be a tag. These branches are then thrown
away when they served their purpose.
> It would help how the current work on e.g. the bookworm or
> bookworm-security branches would work with the scheme. From importing
> newer 6.1.y version (and rebasing rt patches) to cherry-pick single
> fixes as needed. How then merge viceversa the security and stable
> branches for instance.
No merges between release branches are ever performed. Only merge
requests can be merged into those and then cherry picked further down.
You create a new branch from a suitable state.
> (work on the branch for unstable is similar, though we have there no
> disitinction about the target upload).
Uploads to testing directly are pretty rare and reserved for security
updates. So you would use the same procedure are stable security fixes:
branch to debian/security/6.6.9 and go from there.
I hope that makes it more clear.
Regards,
Bastian
--
You're too beautiful to ignore. Too much woman.
-- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown
Reply to: