19:00:22 <carnil> #startmeeting
19:00:22 <MeetBot> Meeting started Wed Jun  5 19:00:22 2024 UTC.  The chair is carnil. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:22 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:47 <carnil> Hello everybody, so this would be the second weekly kernel-team meeting.
19:00:59 <waldi> hi
19:01:07 <diederik> hi
19:01:10 <bwh> hi
19:01:11 <carnil> Personally I had little time this week, but let's try to still acomplish something
19:01:29 <carnil> #topic meeting structure/organzation, collecting future agenda ideas, feedbacks
19:02:11 <carnil> this should be very quick, but I would like to collect how the impression was from the first meeting, what was missing for you, just itemize what you think we can improve and how we can collect agenda items.
19:02:43 <carnil> if that's useful otherwise we just skip to the first larger topic
19:02:52 <waldi> i have to say i'm not longer so fond of asynchronous irc for meetings like this. the same sense required for communication is also required for checking on things
19:03:14 <bwh> You would prefer a video/audio call?
19:03:39 <miguelinux> hi
19:03:46 <waldi> usually yes, it makes for easier feedback. just the protocol is harder to do
19:04:17 <bwh> I'm open to that but it then requires more effort to take minutes
19:04:18 <waldi> the cloud team switched to using jitsi.debian.social some time ago for example
19:05:32 <waldi> (not that meetbot does minutes, it just transcribes things)
19:05:50 <carnil> I'm open to try it, maybe we would need to elect then someone in charge of takng notes, which is a useful feature as done on IRC, that the protocol is recorded on itself and agreements, ideas, important hilights can saved separately.
19:06:28 <carnil> what helps us to improve in comunication might be tried and if you have done good experience with the cloud team with it personally I would say we can try
19:06:38 <bwh> Well, maybe we can try it next time and after that decide what we want to in future?
19:06:46 <miguelinux> Another option is to use both, Jitsi to talk and IRC to takes notes
19:06:50 <waldi> sounds good
19:07:36 <diederik> Another point: I think *if* we're to discuss bugs, they should be communicated up front
19:07:54 <carnil> let me chair you  both (waldi and bwh as well so you can put yourself as I undrstand agreements in the meeting notes)
19:08:14 <carnil> #chair bwh waldi
19:08:14 <MeetBot> Current chairs: bwh carnil waldi
19:08:28 <diederik> To know what the bug is about you need to at least read it. And possibly do some investigation into the bug too. That's impossible if the bug is announced during the meeting
19:08:54 <bwh> #agreed Use Jitsi for next meeting, then decide which medium to use in future
19:08:59 <bwh> (Is that right?)
19:09:03 <waldi> yes
19:09:22 <bwh> Has anyone else tried using the find-recent-urgent script or is it just me?
19:09:36 <carnil> diederik: yes that was somehow chaotic last time, because it was not clear that I used the script from bwh to collect what would be the recent issues tackled
19:09:38 <waldi> diederik: this means we need to create an agenda upfront
19:09:43 <carnil> bwh: I used it
19:09:55 <diederik> I have tried it when first published, but I think it selects the wrong things
19:10:09 <diederik> waldi: yep. At least for the bugs part
19:10:29 <carnil> one idea is that we create a pad/gobby document/something where we collect agenda point, then obviously someone needs to prioritize these
19:10:36 <iam_tj[m]1> Usually there should be an agenda at least 24 hours beforehand; sometimes via a well-known Wiki page (I have considerable experience with online tech meets) and a bug list would be one obvious permanent item
19:11:04 <diederik> the script also incentivises bad behavior. You want it discussed? Make (some random) change to your bug or MR and it will get on the agenda
19:11:37 <waldi> carnil: please not another protocol. gitlab can do wiki, which is also just another git repo
19:11:40 <bwh> diederik: Doesn't mean we don't dismiss it quickly
19:11:58 <diederik> Also, not every bug needs to be discussed by the team.
19:12:13 <diederik> bwh: I think it's a cool tool, don't get me wrong :)
19:12:15 <waldi> carnil: this could also be the minutes store
19:12:18 <bwh> Every bug should get addressed by someone, and at present that doesn't seem to happen
19:12:34 <waldi> yeah
19:12:36 <diederik> And that's what I complete agree with
19:13:14 <diederik> IME handling a bug takes time. You often need to guide the reporter in order to get further
19:13:22 <carnil> waldi: I'm fine with doing using what we can on gitlab
19:13:48 <carnil> (sorry that was badly worded, wanted to say, yes fine to use gitlab)
19:13:50 <diederik> They sometimes need to do things, which take time to do and often also incurs some learning like how to build a kernel
19:14:24 <diederik> So it's not uncommon that from start to finish will take weeks, sometimes even longer
19:14:43 <diederik> so yes, it's very handy if the same person deals with that bug every time
19:15:15 <bwh> So what I would like to see is (1) for each updated bug that requires response, someone takes responsibility (2) we don't let RC bugs linger
19:15:34 <diederik> that sounds useful :)
19:15:42 <bwh> Ideally we can get to a point where that requires very little discussion per bug
19:16:13 <diederik> I've often also wanted (or kept) 'private' notes with things to keep in mind. We could store those things centrally
19:16:38 <bwh> I just have to step away a moment to get my charger
19:16:45 <diederik> And some kind of calendar. You asked for moreinfo? Set a reminder for 1/3 months from now to make sure there is a follow up
19:16:54 <waldi> diederik: issues in gitlab can contain private comments. but is not the bts
19:17:57 <bwh> back
19:18:37 <diederik> waldi: I didn't know that, thanks :)
19:18:39 <waldi> we could use it and make shadow issues, including due dates
19:18:53 <carnil> One way to claim repsonsibilty of a taking on the bug would be to set oneself as 'owner'
19:19:01 <diederik> Those 'private' things were notes which imo didn't belong in that bug report
19:19:04 <bwh> So I think we're in agreement that we need a common list of bugs/items to look at but not how we generate and store that
19:19:19 <iam_tj[m]1> Generally a bug would only get on a meeting agenda if the triager wants team insights or feedback or if it seems to have got 'stuck' - a note on a bug report with simple "remind: $(date_time)" can work well to be easily automatically harvested
19:19:26 <carnil> but I'm not sure we put ourself too much on our shoulders starting to 'claim' bugs. Somethimes you have input on what to try next, but are not able to guide the reporter from the start to the end
19:19:30 <diederik> iam_tj[m]1: +1
19:20:25 <diederik> I think it's useful and needed to attract new contributors and they can start with triaging bugs
19:20:56 <iam_tj[m]1> I wouldn't be averse to writing a tool to harvest 'remind:' notes from BTS and writing a calender page in Wiki format
19:22:25 <diederik> I don't know how or where that should be done/stored, but somewhere does seem useful
19:22:47 <carnil> #info We seem to have agreemnt on that we need a common list of bugs/item to look at and known for the agenda advance the meeting but it needs yet understanding how we generate and where to store it
19:22:48 <iam_tj[m]1> The earlier suggestion to harness Salsa gitlab wiki makes sense
19:23:21 <carnil> #info using gitlab/salsa (wiki) was suggested to use to collect and prioritize item points for the agenda of each next meeting
19:23:55 <diederik> that's not how I understood it
19:24:55 <diederik> bugs for the next meeting could also be stored in salsa, but I thought it was about bug triaging data to store in salsa
19:25:02 <carnil> diederik: can you reword it as you understood it?
19:25:02 <iam_tj[m]1> An extension of the 'remind:' idea could be to extend that to flag a bug for inclusion in the "next" agenda. Benefit of that is the triager/owner of the bug can include that easily in their existing workflow without having to "step away" into another tool
19:25:04 <carnil> thanks
19:25:58 <diederik> IOW: store bug data in salsa does not automatically put it on the team agenda
19:26:26 <iam_tj[m]1> Correct; you'd never want every tracked bug on an agenda
19:27:19 <bwh> How about I change find-recent-urgent to make a list on a wiki, then people can cross items off before the meeting that are already beign handled?
19:29:42 <diederik> I think tooling can/should help. Maybe it's the 'urgent' part of the tool name where I have a 'problem' with
19:30:14 <diederik> I don't think urgent items to be discussed in the team can be automatically selected
19:30:43 <carnil> think of it of "with recent activity"
19:30:50 <bwh> it's "recent or urgent" (where urgent actually just means RC bugs)
19:30:59 <bwh> oh and issues that are due soon
19:31:49 <diederik> I do think it's good to prioritize RC bugs and those can be automatically selected
19:33:02 <diederik> But f.e. last weeks bugs where ema and iam_tj[m]1 worked on last week, I urgent and important, but I (technically) don't consider it RC. (Final judgement ofc to the maintainers)
19:33:39 <diederik> s/I/was/
19:34:48 <diederik> That was the only bug where *I* thought it should be discussed *in the team*
19:35:36 <waldi> hmm, things we can code around the bts
19:36:08 <bwh> The BTS API is really bad :-/
19:36:30 <waldi> yes
19:36:41 <diederik> debbugs hasn't been in a Stable release for 6+ years (?)
19:37:19 <bwh> But so long as it is the Debian BTS, we have to find some way to work with it
19:37:43 <waldi> thats why i think: let's build the stuff around the gitlab api. yes, we need some sync. but we get: a lot more sorting and tagging capability, due handling
19:37:47 <diederik> agreed.
19:39:22 <bwh> I disagree as I think it will require more work than it is worth to do that synchronise
19:39:34 <diederik> I realize making tooling is fun, but I don't consider the tooling the reason why we're again over 1000 open bugs
19:39:39 <carnil> so I think we do not have an agreement right now on what we actually want to put on next meeting agendas, and how/where we put this. is now my understanding correct this time?
19:39:40 <bwh> I don't want to stand in the way of anyone trying it but we should not wait for that to be done
19:39:55 <diederik> my 'agreed' was in relation to using the Debian BTS
19:41:25 <iam_tj[m]1> incremental changes are usually better than throwing out existing and moving to something new, but having a repository of 'team-only' WIP notes for important/noteworthy bugs could be helpful.
19:41:27 <diederik> The problem was that most of the bugs didn't get a response at all (which could mean no one looked at it?)
19:41:41 <bwh> Right
19:42:49 <bwh> How about it we send proposals to the list and then we can discuss those next time?
19:43:09 <carnil> sound bood bwh
19:43:31 <diederik> Similar for MRs. Several MR have been open for months (and my 'favorite' has just crossed the year mark)
19:43:49 <carnil> because we have advanced already really fast in time and are already at the end again
19:44:25 <diederik> having an agenda in advance sound like a really good idea
19:46:54 <bwh> Yes certainly
19:47:01 <carnil> so I propose that for the next meeting to have it more structured, we have the agenda published ~24h in advance. How we collect those and where we store those items to put on the agenda and then shuffle/proritize them for the discussion is yet open. But we should try to put some effort in make that happening.
19:47:03 <iam_tj[m]1> I'd suggest an agenda item for "bug management proposals" and instead of discussing the detail, simply review any "published" proposals (whether from mailing list, wiki, or where-ever) that have been notified at least 24 hours before the meeting. That way the meeting focuses more on the yes/no/not sure than the detail (until some proposal gains significant support and impetus)
19:47:33 <carnil> to have it happend we choose a tool we now know while we search for the right place
19:47:46 <diederik> Start a mail thread "Agenda items for meeting dd CCYY-MM-DD" ?
19:48:10 <iam_tj[m]1> it's good to get into a flow of expecting to have to review some items in the 24 hours before each meeting, as a general workflow to expedite things
19:48:49 <iam_tj[m]1> That's a good way to do it, possibly collate suggested items on a wiki page and then 24 hours before the meeting send the email to ML
19:49:05 <miguelinux> maybe start with the email with the topics and agenda, then look for the storage/wiki
19:49:22 <carnil> diederik: if done via mail this needs to start very early so we have items for the next meeting, so the storing part would be ideal in a "tool" like a wiki or a pad IMHO
19:49:25 <iam_tj[m]1> Wiki makes it easy to also track what needs carrying over to future meetings (ML things tend to disappear into the rear view mirror)
19:49:40 <diederik> I meant send an email to the ML with the mentioned title and then people can respond to that with their ideas/suggestions
19:50:02 <iam_tj[m]1> After a meeting the decisions can be added to the wiki page that carries the agenda, so everything stays in one place
19:50:10 <diederik> carnil: Yeah. I don't see a problem in that
19:51:04 <carnil> waldi, bwh comments on it? Otherwise I would suggest we conclude it with this agreement to start a mail thread to collect points agenda points for the next meeting and put/store them in a wiki pad asp reparation.
19:51:23 <bwh> Agreed
19:51:24 <waldi> sounds good
19:52:14 <carnil> #agreed Agreed on starting a mail thread on debian-kernel for collecting agenda item for the next meeting and store the item for further priorization in the meeting in a wiki
19:53:04 <carnil> #action carnil starts a mails thread on debian-kernel list to start this collection and takes for the first round repsonibiltiy to put the items in a wiki
19:53:31 <carnil> should we end the meeting for today? I guess it becomes to much to pick now any other topic
19:54:35 <waldi> yes
19:54:41 <carnil> personally I would really like we can take at some point the dicussion on firmware-nonfree rebases, linux 6.9.y 6.10~rcX imports, and issues about the trixie kernel maintenance. But that's really far off for today.
19:55:22 <bwh> Yes they will have to wait. Hopefully some will actually be resolved by next week anyway. :-)
19:55:26 <waldi> carnil: yes, we need to discuss that urgently
19:55:53 <diederik> carnil: looks like you already have an item to put on the agenda in the ML thread ;)
19:56:04 <iam_tj[m]1> Something that can work for time-constrained meetings - set a time limit for item discussion. That incentivises people to focus and move quickly 🙂
19:56:12 <bwh> waldi: Which one?
19:56:31 <carnil> okay so I would like to thank all who partecipated to this round of meeting and to put time into improving our team situation
19:57:35 <diederik> cheers :)
19:57:47 <carnil> #endmeeting