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
