Re: Proposal: Switch to linear git history
Hi,
On Mon, Jan 15, 2024 at 09:58:44AM +0100, Bastian Blank wrote:
> 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.
>
Basically, Is the proposal use the same schema as Linux repo does?
Use master/main as the main branch where all the new contributions goes in
and then cherry-pick from it to the others branches.
So, it will usefull to use some scripts to cherry-pick and format the
commit message with the "upstream commit id" as stable and LTS branches does
on Linux.
> > 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,
Miguel
Reply to: