19:00:23 <waldi> #startmeeting
19:00:23 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:31 <waldi> #chair bwh carnil
19:00:31 <MeetBot> Current chairs: bwh carnil waldi
19:00:41 <waldi> welcome to todays meeting of the debian kernel team
19:01:38 <waldi> we don't have any additional points to add to the agenda
19:02:45 <waldi> #topic Branches and merges used for linux
19:03:13 <waldi> i want to bring up this topic. we never really discussed that in a meeting at all
19:03:32 <bwh> OK
19:03:49 <waldi> #link https://lists.debian.org/msgid-search/20240613184840.j2xsk6zl3vnzrwnf@shell.thinkmo.de
19:04:52 <waldi> not sure where to start. i tried to write up everything in the past
19:06:27 <waldi> 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 <waldi> this would remove the large uncontrolled merges done between sid/master and stable/security
19:08:26 <waldi> 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 <waldi> not sure what to say more
19:09:19 <bwh> 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 <bwh> 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 <waldi> which part of DEP-14. and why is it better then per version?
19:10:52 <bwh> Every way in which linux is special and different is a barrier to other developers to work on it
19:11:13 <waldi> what barrier do you see?
19:11:51 <waldi> 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 <bwh> That the branch naming would be different from every other package
19:12:15 <bwh> or, sorry, most packages (assuming DEP-14 does get used)
19:13:35 <waldi> 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 <waldi> we can also create debian/dist and make it non-linear. which is then really confusing
19:14:38 <waldi> or do --theirs merges, even more confusing
19:14:58 <bwh> I think only unstable and -backports would be like that, right?
19:15:16 <waldi> -backports would go away anyway
19:15:47 <waldi> -security would as well
19:15:54 <waldi> everything can just jump
19:16:51 <bwh> waldi: Sorry, no. Backports may need substantial changes, unfortunately.
19:18:00 <carnil> 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 <carnil> 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 <bwh> 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 <carnil> 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 <waldi> carnil: debian/release/6.1 will carry 6.1.110 and 6.1.111
19:20:52 <waldi> 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 <waldi> bwh: aka to make it right we need to fold those changes back into the unstable releases
19:21:30 <bwh> No, we don't
19:21:52 <bwh> The whole point is there are places where backports and unstable need to diverge
19:22:27 <waldi> 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 <waldi> manual unreviewed work
19:23:14 <bwh> Yes, sometimes we need to apply our brains to carry out a merge
19:23:41 <waldi> and you just talked about barries of using different branch names
19:23:56 <bwh> I do see that there are problems with difficult merges from sid to master
19:24:24 <bwh> but your proposal that we shouldn't do merges between other branches seems a step too far for me
19:26:26 <bwh> (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 <bwh> I think we would need separate debian/6.10/trixie and ebian/6.10/bookworm-backports branches
19:29:03 <waldi> 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 <bwh> and the debian/*/bookworm-backports changes (small as they are) would get rebased onto each new debian/*/trixie branch
19:29:34 <waldi> or debian/bookworm-backports/6.10
19:31:04 <waldi> and then we can start to reduce the backports delta. i already somehow started dist depending config entries
19:31:23 <bwh> Yes that will be helpful
19:32:46 <carnil> would it make sense to make a subproject of our team to make a poc how that all would look like?
19:32:51 <waldi> 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 <waldi> carnil: which part of it?
19:33:56 <bwh> I have some quibbles with the names but I guess we can better discuss that in email
19:34:02 <waldi> 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 <waldi> okay
19:34:26 <waldi> bwh: please repond to that email
19:34:35 <bwh> OK
19:35:19 <waldi> carnil: if you have specific questions, please ask
19:35:29 <waldi> #action bwh to respond to the linked email
19:35:32 <waldi> okay
19:36:12 <waldi> anything else on this?
19:36:39 <carnil> 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 <carnil> debian/release/6.1 ?
19:37:12 <waldi> carnil: yes, that is what i mean
19:38:16 <carnil> 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 <waldi> the bts still knows that
19:38:31 <carnil> but we can switch topic, I do not want to block now
19:39:01 <bwh> carnil: You would have to mark the bug fixed in both versions. I think
19:39:08 <waldi> 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 <waldi> bwh: which a Closes in the changelog will do
19:39:39 <bwh> right
19:40:43 <waldi> # topic #1063754 - fat-modules: SD corruption upon opening file on Linux desktop
19:40:46 <waldi> #topic #1063754 - fat-modules: SD corruption upon opening file on Linux desktop
19:41:04 <bwh> Ugh, yes I still have to reply to this
19:41:27 <waldi> #action bwh to respond to #1063754
19:41:36 <waldi> okay. i don't have anything else on this
19:42:20 <waldi> #topic #1080492 - firmware-nonfree: [i915] With 20240709-2, the external monitors randomly blank for 2-3 seconds (regression)
19:43:58 <bwh> This looks like nonsense to me
19:44:22 <bwh> None of the graphics firmware changed in that version
19:45:16 <bwh> #action bwh will close #1080492
19:45:25 <waldi> okay
19:45:39 <waldi> okay. i think we are out of time
19:45:42 <waldi> #topic AOB
19:46:00 <waldi> i won't be able to join the next two weeks
19:46:01 <bwh> Yes, #1065416
19:46:19 <waldi> #topic #1065416
19:46:27 <bwh> Any objections to reverting the Provides until this issue is decided?
19:46:45 <waldi> okay
19:47:25 <carnil> no objections
19:47:36 <bwh> waldi: Will you do that or shall I?
19:47:51 <waldi> i'll do that
19:47:56 <bwh> OK, thank you
19:48:25 <waldi> #topic AOB
19:48:54 <carnil> no other topics today
19:49:19 <waldi> who wants to chair next weeks meeting? it seems like it's bwh's turn
19:49:30 <bwh> OK, I can do that
19:49:33 <waldi> thanks
19:49:40 <carnil> thank you
19:49:42 <waldi> nothing else from me
19:50:04 <bwh> Thanks for chairing
19:50:07 <waldi> thank you all for showing up
19:50:11 <waldi> #endmeeting