19:00:23 #startmeeting 19:00:23 Meeting started Wed Sep 11 19:00:23 2024 UTC. The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:31 #chair bwh carnil 19:00:31 Current chairs: bwh carnil waldi 19:00:41 welcome to todays meeting of the debian kernel team 19:01:38 we don't have any additional points to add to the agenda 19:02:45 #topic Branches and merges used for linux 19:03:13 i want to bring up this topic. we never really discussed that in a meeting at all 19:03:32 OK 19:03:49 #link https://lists.debian.org/msgid-search/20240613184840.j2xsk6zl3vnzrwnf@shell.thinkmo.de 19:04:52 not sure where to start. i tried to write up everything in the past 19:06:27 what i proposed was, in a nutshell: remove all the large branch merges from linux maintenance and instead consider every version as it's own branch that ends 19:07:31 this would remove the large uncontrolled merges done between sid/master and stable/security 19:08:26 yes, it is different to what debian usually does. but so is the package itself anyway. we just use every available debian suite 19:09:07 not sure what to say more 19:09:19 So I think I have 2 issues with this: (1) it goes against the general move to DEP-14 (2) it potentially adds more work for applying bug fixes 19:10:11 Potentially we could deal with (1) by having soem kind of automation for pointing DEP-14 branches at the appropriate upstream-version branches 19:10:15 which part of DEP-14. and why is it better then per version? 19:10:52 Every way in which linux is special and different is a barrier to other developers to work on it 19:11:13 what barrier do you see? 19:11:51 you can already not detect the branch from the package you have or the distribution you are on. you need to know where to look 19:11:55 That the branch naming would be different from every other package 19:12:15 or, sorry, most packages (assuming DEP-14 does get used) 19:13:35 yes. but for what usecas is this a barrier? we can even write the correct branch names into the Vcs headers if we want, so we can then automatically find the correct one, which we with the per-dist branches cant 19:14:21 we can also create debian/dist and make it non-linear. which is then really confusing 19:14:38 or do --theirs merges, even more confusing 19:14:58 I think only unstable and -backports would be like that, right? 19:15:16 -backports would go away anyway 19:15:47 -security would as well 19:15:54 everything can just jump 19:16:51 waldi: Sorry, no. Backports may need substantial changes, unfortunately. 19:18:00 so from my perspective I work mainly on the stable branches as you know. I fail in my understanding still how I would need to handle imports of say now 6.1.110 and later on decide if it goes via bookworm-security or bookworm for the upcoming point release. From what I udnersand in the proposal I would need to create first a debian/release/6.1.110, then from there continue to handle the preparation, 19:18:06 and assuming I do not release 6.1.110-1, and 6.1.111 is released, I do fist create another branch debian/releases/6.1.111 (on top of debian/releases/6.1.110?) 19:18:15 waldi: Sometimes it's as simple as adding a changelog entry; other times we may need extra patches, config changes, etc., and those may need to be carried across upstream version updates 19:19:10 so I have (ersonal) difficulties to understand how I am supposed to do that, but again I'm staying mostly quiet because I'm not fully following how to handle it 19:19:12 carnil: debian/release/6.1 will carry 6.1.110 and 6.1.111 19:20:52 bwh: yes. and those changes are exactly the problem we have here. you need to know which changes happened on which side 19:21:23 bwh: aka to make it right we need to fold those changes back into the unstable releases 19:21:30 No, we don't 19:21:52 The whole point is there are places where backports and unstable need to diverge 19:22:27 yes, we do. because if changes conflict, you will need to read all changes to see again which belongs where. this is manual work 19:22:44 manual unreviewed work 19:23:14 Yes, sometimes we need to apply our brains to carry out a merge 19:23:41 and you just talked about barries of using different branch names 19:23:56 I do see that there are problems with difficult merges from sid to master 19:24:24 but your proposal that we shouldn't do merges between other branches seems a step too far for me 19:26:26 (Oh, but then if we don't merge sid to master, I'll then have problems merging the new-release branch to -backports.) 19:28:34 I think we would need separate debian/6.10/trixie and ebian/6.10/bookworm-backports branches 19:29:03 okay. then lets continue to merge backports. i would do debian/release/6.10 and debian/backports/6.10 for now then 19:29:06 and the debian/*/bookworm-backports changes (small as they are) would get rebased onto each new debian/*/trixie branch 19:29:34 or debian/bookworm-backports/6.10 19:31:04 and then we can start to reduce the backports delta. i already somehow started dist depending config entries 19:31:23 Yes that will be helpful 19:32:46 would it make sense to make a subproject of our team to make a poc how that all would look like? 19:32:51 carnil: normal releases would go to debian/release/6.1. in the case an older version needs to be re-surected for new -security uploads, it would be given a new home in debian/security/6.1.110 19:32:59 carnil: which part of it? 19:33:56 I have some quibbles with the names but I guess we can better discuss that in email 19:34:02 right now it's just new branches plus the decision to not merge back sid into master (and maybe bookworm-security into bookworm) 19:34:05 okay 19:34:26 bwh: please repond to that email 19:34:35 OK 19:35:19 carnil: if you have specific questions, please ask 19:35:29 #action bwh to respond to the linked email 19:35:32 okay 19:36:12 anything else on this? 19:36:39 waldi: let me put it own words to see if I undestand. I import in debian/release/6.1 all nee stable series 6.1.y, now asume I'm already on 6.1.111 there, but we need an urgent fix on top of 6.1.106-3 via security, I would branch off from the debian/6.106-1? or 6.106-3 actuall, tag a new branch debian/security/6.1.106, make a 6.1.106-4 release and then *not* merge the changes back to 19:36:45 debian/release/6.1 ? 19:37:12 carnil: yes, that is what i mean 19:38:16 don't we loose then the information aobut the fix in 6.1.106-4 later on when 6.110+ get released? I mean if I specifically close a bug there, and then not merging back, then we have lost that information. But in general i guess I get your idea (slowly, sorry ;-)) 19:38:28 the bts still knows that 19:38:31 but we can switch topic, I do not want to block now 19:39:01 carnil: You would have to mark the bug fixed in both versions. I think 19:39:08 but with merges you will suddenly tell everyone: this is fixed in 6.1.110 as well, even if the fix was introduced in 6.1.111 19:39:33 bwh: which a Closes in the changelog will do 19:39:39 right 19:40:43 # topic #1063754 - fat-modules: SD corruption upon opening file on Linux desktop 19:40:46 #topic #1063754 - fat-modules: SD corruption upon opening file on Linux desktop 19:41:04 Ugh, yes I still have to reply to this 19:41:27 #action bwh to respond to #1063754 19:41:36 okay. i don't have anything else on this 19:42:20 #topic #1080492 - firmware-nonfree: [i915] With 20240709-2, the external monitors randomly blank for 2-3 seconds (regression) 19:43:58 This looks like nonsense to me 19:44:22 None of the graphics firmware changed in that version 19:45:16 #action bwh will close #1080492 19:45:25 okay 19:45:39 okay. i think we are out of time 19:45:42 #topic AOB 19:46:00 i won't be able to join the next two weeks 19:46:01 Yes, #1065416 19:46:19 #topic #1065416 19:46:27 Any objections to reverting the Provides until this issue is decided? 19:46:45 okay 19:47:25 no objections 19:47:36 waldi: Will you do that or shall I? 19:47:51 i'll do that 19:47:56 OK, thank you 19:48:25 #topic AOB 19:48:54 no other topics today 19:49:19 who wants to chair next weeks meeting? it seems like it's bwh's turn 19:49:30 OK, I can do that 19:49:33 thanks 19:49:40 thank you 19:49:42 nothing else from me 19:50:04 Thanks for chairing 19:50:07 thank you all for showing up 19:50:11 #endmeeting