Re: Proposal: Switch to linear git history
On Fri, 2024-09-20 at 18:53 +0200, Bastian Blank wrote: > Hi > > On Wed, Sep 18, 2024 at 04:53:09PM +0200, Ben Hutchings wrote: > > On Thu, 2024-06-13 at 20:48 +0200, Bastian Blank wrote: [...] > > > > ## Proposal > > > > > > > > Stop merging back changes, but create version distinct branches. > > > > Something like that: > > > master: uploaded to experimental > > Call this debian/latest so we follow DEP-14 as far as possible. > > I'm a bit reluctant on the latest, but well. The rest of the world > agreed on main. I know, but this is the Debian way. > > > -> debian/release/6.6: uploaded to unstable and stable releases > > >-> debian/security/6.6.1+1: extra security releases > > I would prefer to use suite names in these branch names, to make > > itclearer what the branches correspond to. So those would be: > > - debian/6.6/unstable > > How do you think the transition to stable will happen? Just leave it > this way? > > I would prefer to directly use the release name, aka > "debian/6.6/trixie", because this is what the package is destined for. I think that's also OK. > That it is uploaded to unstable (or to (testing-)proposed-updates) is > part of the technical implementation, but it does not change our policy > for it (same version range etc, or did I miss some differences?). > > > - debian/6.6/bookworm-backports > > - debian/6.6.1+1/booxie-security [*] > > (swapping the release and suite so that they don't actually conflict > > with DEP-14 branch names). > > Okay. > > We can then also use "debian/6.6/experimental" or "debian/6.6/latest", > if necessary. When would we need those? Are you thinking about how we would switch upstream version in experimental during a freeze? Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Re: Proposal: Switch to linear git history
Hi On Wed, Sep 18, 2024 at 04:53:09PM +0200, Ben Hutchings wrote: > On Thu, 2024-06-13 at 20:48 +0200, Bastian Blank wrote: > > What is not longer possible in non-confusing ways is to use branches > > named after Debian distributions. We would either need to do non fast > > forward or do --their merges. Both variants are highly confusing to > > users and the later one even got the same problems that I just described > > above. > For testing/unstable and for stable-backports suites I agree we > shouldn't do this any more. The -backports changes will need to > rebased when switching from e.g. 6.10.x to 6.11.x. Okay. We can then still work on reducing the differences and maybe at same time we only have a single changelog entry left. But this is for another day. > Having said that, a rebase isn't much more reviewable than a merge, so > I would prefer not to rebase -backports for upstream stable updates. > While merges for such updates are not automatic, the conflicts are in > practice trivial. Those are forward merges, not in both directions and not including huge version ranges. So that should be way easier manageable. > > > ## Proposal > > > > > > Stop merging back changes, but create version distinct branches. > > > Something like that: > > master: uploaded to experimental > Call this debian/latest so we follow DEP-14 as far as possible. I'm a bit reluctant on the latest, but well. The rest of the world agreed on main. > > -> debian/release/6.6: uploaded to unstable and stable releases > >-> debian/security/6.6.1+1: extra security releases > I would prefer to use suite names in these branch names, to make > itclearer what the branches correspond to. So those would be: > - debian/6.6/unstable How do you think the transition to stable will happen? Just leave it this way? I would prefer to directly use the release name, aka "debian/6.6/trixie", because this is what the package is destined for. That it is uploaded to unstable (or to (testing-)proposed-updates) is part of the technical implementation, but it does not change our policy for it (same version range etc, or did I miss some differences?). > - debian/6.6/bookworm-backports > - debian/6.6.1+1/booxie-security [*] > (swapping the release and suite so that they don't actually conflict > with DEP-14 branch names). Okay. We can then also use "debian/6.6/experimental" or "debian/6.6/latest", if necessary. Bastian -- A father doesn't destroy his children. -- Lt. Carolyn Palamas, "Who Mourns for Adonais?", stardate 3468.1.
Re: Proposal: Switch to linear git history
Hi Bastian, On Thu, 2024-06-13 at 20:48 +0200, Bastian Blank wrote: > Hi folks > > On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > > What did I miss? > > After the discussion in our meeting today, it seems I did not properly > describe the problem good enough. And then we had another discussion in last week's meeting, and I think we finally reached some rough agreement on this. I'm going to try to set out how I understand this would work. > > 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. > > Okay, what we regularly do is merges between sid and master. Those > merges are done by hand, but could be automated to some degree. Doing > them requires the developer to take a lot of decisions in one single > step: I agree that we should stop doing this. We'll need to close bugs on both branches in some cases. [...] > What is not longer possible in non-confusing ways is to use branches > named after Debian distributions. We would either need to do non fast > forward or do --their merges. Both variants are highly confusing to > users and the later one even got the same problems that I just described > above. For testing/unstable and for stable-backports suites I agree we shouldn't do this any more. The -backports changes will need to rebased when switching from e.g. 6.10.x to 6.11.x. Having said that, a rebase isn't much more reviewable than a merge, so I would prefer not to rebase -backports for upstream stable updates. While merges for such updates are not automatic, the conflicts are in practice trivial. For stable and stable-security I think we could continue using codenames as we don't expect to move to a new upstream stable branch (at least, not often). [...] > > ## Proposal > > > > Stop merging back changes, but create version distinct branches. > > Something like that: > > master: uploaded to experimental Call this debian/latest so we follow DEP-14 as far as possible. > -> debian/release/6.6: uploaded to unstable and stable releases >-> debian/backport/6.6.1-1: uploaded to backports (not really > needed in most cases) As I pointed out in the meeting, backports do sometimes need extra patches or kconfig changes so we can't treat them as automatic, even with the proposed changes to add suite-dependent config. And as stated above, I don't want to rebase -backports for every stable update. >-> debian/security/6.6.1+1: extra security releases I would prefer to use suite names in these branch names, to make itclearer what the branches correspond to. So those would be: - debian/6.6/unstable - debian/6.6/bookworm-backports - debian/6.6.1+1/booxie-security [*] (swapping the release and suite so that they don't actually conflict with DEP-14 branch names). Ben. * booxie is the little-known Debian release between bookworm and trixie that included Linux 6.6. :-) -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams signature.asc Description: This is a digitally signed message part
Re: Proposal: Switch to linear git history
Hi folks On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > What did I miss? After the discussion in our meeting today, it seems I did not properly describe the problem good enough. > 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. Okay, what we regularly do is merges between sid and master. Those merges are done by hand, but could be automated to some degree. Doing them requires the developer to take a lot of decisions in one single step: - The changelog could be managed automatically. - Added patches are usually meant just for this version and thus dropped (modified patches are unclear). - Other changes usually remain. But, especially for the last two, exceptions might be possible and can't be detected without revisiting every change in between one by one. Also those merges are not reviewed the normal way via merge requests. This makes those merge high risk, because - too broad changes can be merged, - changes can vanish, - the changes are unverified, and - inside large merges it is way easier to hide things. What we get from the merges is - a linear changelog, - the ability to select where to apply changes first, and - the ability to use per Debian distribution branches without confusing users. The linear changelog will make version tracking easier. However it is actually a lie. In certain cases it is correct (patch to 6.10 merge window and backported to 6.9.3, bug marked as fixed in 6.9.3). But in others it is a lie (breakage in 6.9.1, patch in 6.9.2). So it should be better to explicitly close such bugs in both 6.9.2 and 6.10~rc1. We also don't really need to select early where a patch should be applied. We can just backport merge requests to different branches, and we can even create some scripts to make it easier. Normal changes to to master, version specific fixes directly to this version. This also reduces the mental load for submitters, as they can always start at the master branch. What is not longer possible in non-confusing ways is to use branches named after Debian distributions. We would either need to do non fast forward or do --their merges. Both variants are highly confusing to users and the later one even got the same problems that I just described above. I believe we have to remove this task that currently is only done by three people. This is the reason why I propose branching schemes based on actual versions and not Debian distributions. > ## Proposal > > Stop merging back changes, but create version distinct branches. > Something like that: master: uploaded to experimental -> debian/release/6.6: uploaded to unstable and stable releases -> debian/backport/6.6.1-1: uploaded to backports (not really needed in most cases) -> debian/security/6.6.1+1: extra security releases Bastian -- Beam me up, Scotty, there's no intelligent life down here!
Re: Proposal: Switch to linear git history
Hi Ben On Mon, Jan 29, 2024 at 03:37:37PM +0100, Ben Hutchings wrote: > On Sun, 2024-01-28 at 21:37 +0100, Bastian Blank wrote: > > I have one small last minute modification: don't use main, but release. > > Overall I did not see any voices against the concept itself. Nor did I > > see any counter proposals to the layout. > I oppose this change and I propose to switch to DEP-14 branches > instead. Okay. Please provide a real description. DEP-14 does not specify workflow, only layout. And git does not like non fast-forward branches at all, so how do you intend to fix that? As this comes only after five weeks, please don't do that again. Bastian -- It would be illogical to kill without reason. -- Spock, "Journey to Babel", stardate 3842.4
Re: Proposal: Switch to linear git history
On Sun, 2024-01-28 at 21:37 +0100, Bastian Blank wrote: > Hi > > I have one small last minute modification: don't use main, but release. > Overall I did not see any voices against the concept itself. Nor did I > see any counter proposals to the layout. I oppose this change and I propose to switch to DEP-14 branches instead. Ben. > This means: > - The current sid branch will end with 6.6 and be cleaned up later > - No more merges will be done up the chain > - I will branch to debian/release/6.7 after !1011 is in > - I will annonce 6.7 upload to unstable pretty soon > > On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > > master: uploaded to experimental > -> debian/release/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 > > Bastian > -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams signature.asc Description: This is a digitally signed message part
Re: Proposal: Switch to linear git history
Hi I have one small last minute modification: don't use main, but release. Overall I did not see any voices against the concept itself. Nor did I see any counter proposals to the layout. This means: - The current sid branch will end with 6.6 and be cleaned up later - No more merges will be done up the chain - I will branch to debian/release/6.7 after !1011 is in - I will annonce 6.7 upload to unstable pretty soon On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > master: uploaded to experimental -> debian/release/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 Bastian -- Even historians fail to learn from history -- they repeat the same mistakes. -- John Gill, "Patterns of Force", stardate 2534.7
Re: Proposal: Switch to linear git history
On Wed, Jan 17, 2024 at 08:06:18PM +0100, Bastian Blank wrote: > On Wed, Jan 17, 2024 at 07:18:27PM +0100, Ben Hutchings wrote: > > > On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > > > > 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. > > > > I agree that this is a waste of time and resources for feature > > branches. We ought to avoid that by automating changelog updates for > > changes to the Debian packaging (gbp dch or somethign similar). > Feature branches are not affected here. Okay, I was not clear enough. But I was only talking about release branches right now. For feature branches we use merge requests, where GitLab can do what you tell it to. But merges there are fine. > > If we're going to change branch naming then we should be moving towards > > DEP-14, but this seems to diverge further. > I don't find any branches with version in DEP-14. So this is not even > applicable here. Well, DEP-14 defines debian/. Then suite is main/6.6 and so it fits perfectly. Bastian -- Superior ability breeds superior ambition. -- Spock, "Space Seed", stardate 3141.9
Re: Proposal: Switch to linear git history
On Wed, Jan 17, 2024 at 07:18:27PM +0100, Ben Hutchings wrote: > > On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > > > 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. > > I agree that this is a waste of time and resources for feature > branches. We ought to avoid that by automating changelog updates for > changes to the Debian packaging (gbp dch or somethign similar). Feature branches are not affected here. > But I've never found these conflicts to be a big problem when merging > between different branches. I always do. Which part needs to come from where? debian/changelog from both, debian/config from both, but don't try to get debian/patches from both sides. > > > 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.) > > If we're going to change branch naming then we should be moving towards > DEP-14, but this seems to diverge further. I don't find any branches with version in DEP-14. So this is not even applicable here. > Do you see any advantages to this beyond avoiding conflicts? It removed useless work. Bastian -- The idea of male and female are universal constants. -- Kirk, "Metamorphosis", stardate 3219.8
Re: Proposal: Switch to linear git history
On Sat, 2024-01-13 at 13:10 +0100, Bastian Blank wrote: > Moin > > Sadly I did not get any response. > > Bastian > > On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > > 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. I agree that this is a waste of time and resources for feature branches. We ought to avoid that by automating changelog updates for changes to the Debian packaging (gbp dch or somethign similar). I would also support squashing feature branches that have a messy history. But I've never found these conflicts to be a big problem when merging between different branches. [...] > > > ## 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.) If we're going to change branch naming then we should be moving towards DEP-14, but this seems to diverge further. Do you see any advantages to this beyond avoiding conflicts? Ben. -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams signature.asc Description: This is a digitally signed message part
Re: Proposal: Switch to linear git history
On Monday, 15 January 2024 14:07:42 CET Emanuele Rocca wrote: > A partial explanation for the confusion is that right now the master > branch is where you land changes that target experimental, while the sid > branch is for changes targeting sid. However, obviously not all commits > end up in Debian experimental - And my proposal is that 'all' changes (refactorings/new modules) target the master branch which then land in Experimental first. And when the time is right (usually around version .0/.1/.2), then it gets uploaded to Sid. But imo new features/modules should NOT go directly to Sid. > but the guideline is to always send changes to master anyways. I don't think such a guideline exists, at least not 'formally'. There currently is just 1 (old) MR targeting Sid, but there have been more in the past. I just checked the merged MRs and the current practice does seem to be targeting master, but there are some older ones (>4 months) which went directly to Sid which I think they shouldn't. signature.asc Description: This is a digitally signed message part.
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
Re: Proposal: Switch to linear git history
Hi, On 2024-01-15 01:14, Diederik de Haas wrote: > On Thursday, 21 December 2023 17:30:26 CET Bastian Blank wrote: > > - All changes need to go via master, which they should do anyway. > > I think this as a general rule, with few clearly defined exceptions (like > stable release updates), would be a good thing. Now it feels like targeting > 'sid' is a way to (quickly) 'sneak' in some changes. > Moreover targeting 'sid' or 'master' seems rather arbitrary atm. A partial explanation for the confusion is that right now the master branch is where you land changes that target experimental, while the sid branch is for changes targeting sid. However, obviously not all commits end up in Debian experimental - but the guideline is to always send changes to master anyways. This double role of the master branch, namely landing branch for all changes and branch meant for experimental, is what confuses me at least. Maybe a better approach could be creating an additional branch for experimental, enforcing that all changes go via master, and then merging from master to the "target distribution" branch as needed?
Re: Proposal: Switch to linear git history
I don't feel qualified on the general topic, but ... On Thursday, 21 December 2023 17:30:26 CET Bastian Blank wrote: > - All changes need to go via master, which they should do anyway. I think this as a general rule, with few clearly defined exceptions (like stable release updates), would be a good thing. Now it feels like targeting 'sid' is a way to (quickly) 'sneak' in some changes. Moreover targeting 'sid' or 'master' seems rather arbitrary atm. signature.asc Description: This is a digitally signed message part.
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
Re: Proposal: Switch to linear git history
Hi, On Sat, Jan 13, 2024 at 01:10:50PM +0100, Bastian Blank wrote: > Moin > > Sadly I did not get any response. I have seen it, but have not yet digged into it (in fact marked the mail as important and unread/todo). 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). 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. (work on the branch for unstable is similar, though we have there no disitinction about the target upload). Regards, Salvatore
Re: Proposal: Switch to linear git history
Moin Sadly I did not get any response. Bastian On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > 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 > -- Men will always be men -- no matter where they are. -- Harry Mudd, "Mudd's Women", stardate 1329.8
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
