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
Attachment:
signature.asc
Description: This is a digitally signed message part