14:00:23 <jeremiah> #startmeeting
14:00:23 <MeetBot> Meeting started Thu Nov 25 14:00:23 2021 UTC.  The chair is jeremiah. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:23 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:23 <el_cubano> I'm a bit unconventional like that.  And usually, my family does a pig roast, pig being more common for big family meals in the Caribbean than turkey.
14:00:49 * ta is getting hungry now
14:01:04 <jeremiah> Me as well. ;)
14:01:11 <apo> it's just a rainy, grey day here in Germany, but Happy Thanksgiving to you folks :)
14:01:32 <el_cubano> It is also a rainy, grey day here in the midwestern US
14:01:33 <jeremiah> A rainy day in Northern Europe? How unusual.
14:01:43 <apo> ^^ :)
14:02:29 <jeremiah> #topic Greetings and welcome
14:02:55 <jeremiah> Thanks everyone for coming to the meeting.
14:03:40 <el_cubano> o/
14:03:51 <ta> hi everybody
14:03:51 <bunk> .
14:03:52 <apo> hiho
14:03:56 <jeremiah> We'll get off to a rolling start as it is harder to determine if everyone is "present".
14:04:09 <jeremiah> 0/
14:05:07 <jeremiah> Those who are late to arrive have the benefit of the logs
14:05:27 <jeremiah> Since we have a large agenda, I figure we'll get started.
14:05:36 <apo> yup
14:05:47 <jeremiah> Just a reminder that the agenda is here: https://pad.riseup.net/p/lts-meeting-agenda
14:06:05 <jeremiah> #topic How to avoid having different people working on the same package in LTS and ELTS?
14:06:25 <jeremiah> This topic seem fairly straight forward to me
14:06:32 <bunk> It's an old problem of which I saw an example again this month:
14:07:06 <bunk> Someone (who also has hours in LTS) took samba in ELTS, and 1 day later someone else took samba in LTS.
14:07:39 <bunk> It would be more efficient if packages that get updated in both LTS and ELTS would be handled by the same person.
14:07:43 <bunk> Question: How?
14:08:30 <jeremiah> Is it possible to use a single entry to "take" a package for both LTS & ELTS?
14:08:56 <el_cubano> bunk: Usually, but not always.  I worked on Samba either last year or early this year.  The differences between the LTS and ELTS versions were considerable.  That said, I think in principle your concern is sensible and we should generally try to make sure the same person has the package in both projects, but especially when the versions are very close/identical.
14:09:08 <ta> so why not claim both packages immediately?
14:10:45 <apo> right, but sometimes the two frontdesks don't act at the same time. I can see an outcry again, if someone "circumvents" frontdesk
14:11:07 <apo> I'm totally in favor of letting the same person handle the package for LTS and ELTS
14:11:15 <ta> if this happens just once a month, people could talk to each other ...
14:11:23 <apo> exactly
14:11:41 <apo> talking to each other is my solution to this problem too
14:11:47 <ta> and one can talk to frontdesks as well
14:12:32 <ta> I don't think OCOCOCOCOCOCOCOCOCOCOCOCwe need to think about some procedure here ... just talk to eachother
14:12:37 <el_cubano> I have taken that approach and it seems to work very well (just communicating that is).
14:12:59 <el_cubano> Adding more procedure will likely just bog things down with minimal (if any) additional benefit
14:13:14 <jeremiah> What type of communication do we advise? Is it a note? Drop a message in IRC? An email?
14:13:31 <apo> I'm more concerned about the current practice of claiming too many packages for ELTS. While it is usually ok for LTS, ELTS is different because the scope is much more limited. For instance I could have fixed ntfs-3g by now, and I wanted to talk to utkarsh about it but he seems to be absent
14:13:49 <apo> an email should be fine
14:14:25 <jeremiah> apo: I've had trouble reaching him recently as well.
14:14:54 <ta> yes, if there is no reaction on irc, email would be find
14:14:57 <ta> fine
14:16:52 <jeremiah> #info Greater communication around packages in both LTS and ELTS is wanted. A note on IRC and/or email is helpful to make the claiming of packages more effecient.
14:16:57 <jeremiah> efficient.
14:17:53 <jeremiah> #info claiming too many packages and being incommunicado can delay package fixes from others
14:18:33 <jeremiah> I feel that this transitions well into our next topic;
14:18:41 <jeremiah> #topic Review of unclaimed packages in dla-needed
14:18:57 <bunk> There are 3 unclaimed packages in dla-needed:
14:19:20 <bunk> 1. ansible: The notes read as if apo wanted to take it again after the last buster release?
14:19:54 * petn-randall waves.
14:19:57 <bunk> 2. debian-archive-keyring: neverending(?) story by utkarsh
14:20:06 <apo> no, the maintainer talked to me and wanted to finish the update
14:20:56 <bunk> 3. nvidia-graphics-drivers: I think (to be confirmed) that all 5 CVEs are fixed in the (renamed) package in buster/bullseye/bookworm. Does anyone have supported hardware and does not fear non-free?
14:21:15 <apo> Lee Garrett is the maintainer of ansible, I don't know why he didn't finish it yet
14:21:38 <apo> he is also a LTS team member so it seemed sensible to me to let him handle it
14:22:29 <bunk> petn-randall: ^^^
14:24:14 <apo> I will try to reach out to him and clarify the status of ansible
14:24:37 <jeremiah> I will reach out to Utkarsh and try and clarify the status of debian-archive-keyring.
14:24:57 <apo> ah ok
14:25:19 <apo> petn-randall: so what's up with ansible ? :)
14:26:25 <jeremiah> The Nvidia issue seems a little harder given the requirements. I'm afraid I don't have any Nvidia hardware at hand except for a Trimslice which is Tegra 2 and quite old.
14:28:07 <jeremiah> bunk: Is there another forum we can raise the issue of the unclaimed Nvidia drivers to get more attention?
14:28:15 <apo> same here, but we could ask for testers on the lts mailinglist or maybe -backports? There are usually more people who use Nvidia and request backports of the drivers regularly
14:28:51 <jeremiah> That sounds good
14:28:51 <bunk> This would still need someone to take the package and prepare an update
14:28:52 * el_cubano wonders if there might be an arrangement that could be formed with an individual or a company similar to what we previously had with credativ for Xen support
14:29:35 <jeremiah> There are SMBCs that often are useful in a situation like this.
14:29:36 <bunk> We are looking for one piece of old graphics card from a dumpster...
14:29:53 <jeremiah> Oh.
14:30:39 <apo> can't we just backport the package from Buster and be done with it?
14:31:18 <bunk> It's a different src-package name in buster. Likely still straightforward.
14:32:32 <apo> I would investigate this solution. I can do it after I have finished roundcoube and firmware-nonfree, if nobody else beats me to it, which would be fine too
14:32:56 <jeremiah> Thanks apo
14:33:30 <jeremiah> #action apo to follow up re: Ansible
14:33:47 <jeremiah> #action jeremiah to follow up re: debian-archive-keyring
14:34:17 <jeremiah> #action apo to investigate nvidia drivers backport
14:35:05 <jeremiah> I'll move on to another topic now
14:35:21 <jeremiah> #topic Dispatch change: Feedback/Questions?
14:35:46 <el_cubano> Is this about the dispatch of hours or of front desk weeks?
14:35:57 <bunk> dispatch of hours
14:36:09 <el_cubano> Thanks for confirming
14:36:48 <jeremiah> From my perspective it's gone smoothly.
14:37:07 <jeremiah> The big change will be in doing the monthly report, but I expect that to be significantly easier.
14:37:48 <el_cubano> I intend to start working on the monthly report automation improvement next week.  Though, I doubt I will finish before the next time it will beed to beused.
14:38:00 <jeremiah> That's totally fine.
14:38:03 <bunk> One thing missing is that pinging people happened manually this month, this should either be documented for the 2nd day of the month at 12:00 UTC to be done manually by the coordinator, or someone (preferably not me) should implement a cron job somewhere.
14:38:19 <jeremiah> bunk: yes, that was my miss.
14:38:52 <jeremiah> #action jeremiah to set a reminder that _emails_ need to go out reminding folks to send reports on the 2nd of the month.
14:40:15 <apo> by the way, regarding DLA 2785-1, which hasn't been published yet. I would contact Ben Hutchings directly.
14:40:39 <jeremiah> Ah, okay.
14:40:44 <apo> he probably misses the weekly semi-automatic unclaim emails
14:41:08 <jeremiah> Oh, okay. I've sent a few so you're likely right.
14:41:34 <jeremiah> #action jeremiah to contact Ben directly re: DLA 2785-1 still unpublished.
14:43:03 <jeremiah> #topic Status update: enterprise gradle project
14:43:22 <jeremiah> I'll jump to the work being done on the gradle project
14:43:41 <jeremiah> (We can come back to any topic if we're not completely finished)
14:44:15 <jeremiah> In that project, a lot of investigation has been done and there's good communication between the reviewer and bidder, so we're on a good path.
14:44:48 <el_cubano> That's great news!  I briefly looked into it as I considered submitting a bid.  That project is quite a beast.
14:45:22 <jeremiah> It does look somewhat convoluted with lots of patches, missing pieces, etc.
14:45:46 <apo> yes, it took a while to get a general overview. It's not just about removing the plugin feature, it is also about Kotlin build-depending on openjdk-8 and a lot of patches that may be missing to get an actualy working gradle package
14:47:50 <jeremiah> Folks can follow along in Gitlab on this topic as there is good communication.
14:48:01 <jeremiah> #topic Resolution of CVE assignment tooling for related packages
14:48:19 <jeremiah> This topic came up recently, but it is an older one.
14:48:38 <jeremiah> Beuc: Would you like to add a word or two about this?
14:48:52 <Beuc> I can
14:49:01 <jeremiah> Thank you
14:49:21 <Beuc> The main issue IMHO is exchanging with the security team
14:49:47 <Beuc> There is usually a lot of time when expecting an answer (up to weeks),
14:50:24 <Beuc> and lot of unanswered proposal, meaning we don't know if they are understaffed, uninterested, consider that this doesn't warrant an answer, etc.
14:50:53 <Beuc> I contacted jeremiah to check if there's a way to make cooperation more efficient
14:51:15 <apo> they receive a lot of emails every day and Moritz is currently travelling, so this might explain some of the delays
14:51:40 <jeremiah> Is email the main form of communication and discussion on security topics?
14:51:53 <jeremiah> I see that the IRC channel mostly has KGB communication.
14:53:05 <apo> yes, email is the main form of communication.
14:53:26 <Beuc> apo, this is an on-going topic since February, and the MR is open since september
14:53:26 <el_cubano> I have found that generally, yes, email is the main form.  Different members of the team evlauate different requests and using IRC it isn't guaranteed that the correct person will be available to reply on the spot
14:54:10 <apo> If you don't get a timely response I can bring this discussion up in our security-team IRC chat, I can't promise anything, just joined the team :)
14:54:48 <jeremiah> I'm happy to try to get a response, but it may be better for a team member to address this.
14:55:00 <jeremiah> So thanks apo for volunteering.
14:55:20 <jeremiah> I'm hesitant to insert myself into the communications as I don't want to add to the noise.
14:55:35 <jeremiah> But it seems important to have an answer for buec and others.
14:55:46 <jeremiah> s/buec/Beuc/
14:56:27 <Beuc> jeremiah, sure I didn't expect you to do any direct communication, but possibly advice on better way to handle communication, or possibly contact sectean on behalf of the team to identify communication issues
14:57:18 <jeremiah> Thanks, that's helpful clarification. And something that I feel the administrator ought to do.
14:58:04 <jeremiah> So I propose to try to craft a careful email to the security-team list and ask if there's ways I can help facilitate communication on topics?
14:58:42 <jeremiah> If there's no response, I'll follow up with apo to discuss next steps.
14:58:54 <apo> yes, that's a good plan
14:59:11 <jeremiah> #action jeremiah  craft a careful email to the security-team list and ask if there's ways I can help facilitate communication on topics
15:00:01 <jeremiah> #topic Documentation for Debian Appliance vendors
15:00:22 <jeremiah> There's been good discussion on this topic in email - thanks!
15:00:32 <gladk> oops, it looks like I missed that we have another time for the meeting :)
15:00:54 <apo> gladk: it's winter now :p
15:01:06 <gladk> really?
15:01:14 <jeremiah> Here at least.
15:01:31 <jeremiah> The time changed a couple weeks ago.
15:02:04 <gladk> yes, I know. My google calendar did not make a change there
15:02:10 <gladk> but OK, I will reed the notes there
15:02:29 <jeremiah> I'll send out minutes as well.
15:02:44 <bunk> (BTW: Europe and the US are not changing on the same day)
15:03:14 <jeremiah> If there's more to discuss regarding the package selection for long term support customers, we can continue in the email thread.
15:03:45 <el_cubano> bunk: That's a result of the US stupidly moving the date around
15:03:50 <jeremiah> I reading some of the LTS emails that buxy sends to customers I see that this type of question occurs a lot though.
15:04:16 <jeremiah> And it seems that many folks might benefit from having clearer advice on what to use, what not to use.
15:05:10 <bunk> Someone(tm) has to properly write down the tribal knowledge into policies what is or can be supported.
15:05:17 <jeremiah> +1
15:05:51 <buxy> duh, I missed the meeting, I still have 4pm local time, and Meetbot didn't ping participants here
15:07:18 <jeremiah> I'm happy to continue, in fact we have some more agenda and the backlog holds some good info.
15:07:28 <bunk> buxy: We are currently at the first topic that involves you...
15:08:52 <bunk> (BTW: no, I do not know how Canonical generates Supported in Packages)
15:10:13 <jeremiah> I looked at some scripts they have, namely ubuntu-security-status
15:10:43 <jeremiah> bunk: Is that what you're referring to?
15:10:54 <gladk> we discussed last time fd-weeks-dispatch. Was it discussed today? If we want to change it for 2022, it should be done ASAP. Who decides it?
15:10:57 <bunk> No, that is the client side.
15:11:35 <bunk> gladk: No, this was not (yet?) discussed today.
15:11:49 <el_cubano> gladk: I am actually working on it and should have it ready this weekend.  The llvm-toolchain-11 and rustc updates that I have been working on took more time than expected and I should have them completed today.
15:13:05 <bunk> buxy: I think the Documentation for Debian Appliance vendors needs names of one or few people working on it (and a hours budget).
15:13:17 <gladk> el_cubano: thanks! The problem is what I see not too much people expressed their opinions on that
15:13:42 <bunk> gladk: Ask in AOB whether there are objections?
15:14:03 <gladk> For the first run it could be done even manually, but we need an agreement on that
15:14:20 <gladk> bunk: what is AOB?
15:14:28 <jeremiah> Any Other Business
15:14:43 <el_cubano> I see.  I took the discussion in the last meeting and the follow-up discussion to jeremiah's email to mean that we have a general consensus as captured in the Gitlab issue.
15:14:48 <el_cubano> gladk: ^^
15:15:30 <jeremiah> AoB: The part of the meeting where we've gone through our agenda topics and other questions can be brought up.
15:16:14 <el_cubano> jeremiah: As far as the documenation issue, what is it that appliance vendors are currenly lacking from us?
15:16:58 <jeremiah> Well, I'll quote a bit from the email thread;
15:17:27 <jeremiah> "What customers should pay attention to if they want to ensure that our ELTS offer properly address their needs in terms of security support: when they select the software that they are embeddeding in their product, what should they pay attention to?"
15:17:51 <el_cubano> Ah OK.  I didn't connect this topic with that email discussion.  Thanks.
15:18:14 <jeremiah> In my experience, commercial support for free software is something that a lot of folks are looking for.
15:19:10 <jeremiah> If we had more advice like to those who use Debian in products, it would be a huge help I feel.
15:19:47 <jeremiah> In the automotive industry commercial support was a blocker to adoption of Debian, even though Debian fit the software architecture quite well.
15:20:54 <el_cubano> So, the documenation would be primarily intended to address the concerns that an integrator might have with regards to certifying compliance to corporate policies or other policies.  (Or something along those lines?)
15:21:16 <jeremiah> I don't know if it would be as strong as compliance
15:21:32 <buxy> bunk: I'm happy if ELTS contributors that volunteer to work on this topic spend their regular ELTS hours to address this, and if needed we can grant additionnal hours from the ELTS project funding pool
15:22:08 <jeremiah> el_cubano: I think it would be more about how to get the most out of Debian LTS
15:22:08 <el_cubano> This seems interesting to me (I have a lot of experience for writing documentation in highly regulated environments).
15:22:24 <el_cubano> Is there a Gitlab issue for this yet?
15:22:33 <jeremiah> el_cubano: Let me dig it up . . .
15:23:00 <bunk> My understanding is that what is wanted is documentation (and ideally also tooling) what packages we are able to support in ELTS if there is customer demand.
15:23:07 <buxy> el_cubano: well, when you design a product that is connected to internet and is supposted to run for X years, you want to make sure that you get the corresponding security support. We are doing our best but we are not making any promise. The documentation intends to help them minimize the risk that they are using something we will not be able to support.
15:23:42 <jeremiah> el_cubano: https://salsa.debian.org/freexian-team/extended-lts/website/-/issues/1
15:23:46 <buxy> And help them make smart choices (for example with CIP for the kernel)
15:23:50 <el_cubano> buxy: OK.  And the risk is minimized by explaining whet we support, how support it, and so on?
15:25:26 <buxy> If that information lets you avoid some traps, I'd say yes. We can probably do better than that but it's a start in the right direction.
15:25:40 <bunk> What would that choice be when a customer is evaluating bullseye today for a product?
15:25:56 <el_cubano> jeremiah: I've subscribed to the issue.  Once I finish the FD dispatch script I'll take a look at this issue.
15:26:50 <bunk> IMHO we can document the (few) packages we cannot support (and their many rdeps)
15:27:42 <jeremiah> el_cubano: Terrific - there's also a thread on deblts-team@feexian.com with good info.
15:28:40 <jeremiah> bunk: That seems like it would be a useful start.
15:28:59 <el_cubano> It sounds like the documentation needs at least two sections.  One is the "what we are doing today for jessie (and wheezy?)" and the other is "here is how ELTS support works and how packages are included/excluded (so that integrators can plan for so many years down the road what additional investment they might need to make in ELTS to ensure the things important to them remain supported)"
15:29:36 <petn-randall> apo: I'll work on ansible security fixes on Friday/Saturday. I was hoping that my DD key gets added first, so I can also fix the current CVEs in unstable before I do it for stable/oldstable/oldoldstable.
15:30:08 <apo> petn-randall: ok, great, thanks for your reply!
15:30:52 <jeremiah> el_cubano: I think you'll want a section on the kernel as well.
15:31:07 <buxy> definitely
15:31:22 * el_cubano nods
15:31:39 <jeremiah> https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance
15:32:53 <jeremiah> Kernel selection might be tricky because vendors often offer support, but it is costly. And often the support is insufficient, so companies switch from vendor support to the LF or support in-house.
15:33:48 <jeremiah> This means that choosing a Linux Foundation LTS kernel is non-trivial and then aligning that with Debian LTS in turn can be challenging.
15:34:27 <jeremiah> I imagine that advice and documentation on that process would help lots of people.
15:35:21 <el_cubano> OK.  I see the mentions of the kernel part in the Salsa issue
15:36:25 <jeremiah> If I'm not mistaken Ben is also involved in the LF's LTS kernel and CIP project, he may have more info.
15:36:46 <buxy> He used to be, he no longer is.
15:37:05 <jeremiah> Ah.
15:37:43 <jeremiah> I have to contact him regarding an outstanding DLA, perhaps I'll ask him for any tribal knowledge he may have.
15:38:10 <jeremiah> We're at that point in the meeting where any other business can be taken up.
15:38:22 <jeremiah> #topic Any other business
15:38:22 <buxy> I would be glad if we could find someone to have a try at packaging their SLTS kernel with the usual Debian packaging (.config and patches from the standard Debian kernel) so that we can submit the .config that we want to see suppported from CIP.
15:39:21 <bunk> jeremiah: You intentionally skipped one of your items?
15:40:01 <jeremiah> Not intentionally . . .
15:40:06 * jeremiah reviews agenda
15:40:30 <jeremiah> Excuse me - I missed an important topic
15:41:06 <jeremiah> #topic enforce the use of Git as the DVCS tool for ELTS packages
15:41:37 <jeremiah> I think there's consensus on using git in ELTS packages but perhaps not clear consensus on how we enforce this
15:41:42 <jeremiah> Suggestions?
15:42:10 <bunk> Why? And what git workflow?
15:42:32 <Beuc> I'm worried that this is going to be a hassle especially with large packages (firefox, libreoffice),
15:42:41 <Beuc> I wonder if that could be automated somehow
15:43:04 <apo> I'd prefer a simple gbp-import dsc
15:43:08 <Beuc> either by /not/ removing previous uploads, or auto-committing uploaded packages to some repositories
15:43:23 <Beuc> (server-side)
15:43:28 <el_cubano> Agreed.  In my experience, firefox-esr, thunderbird, libreoffice, and openjdk-* do not lend themselves well to being git-ified with a typical 'gbp import-dsc' invocation
15:43:29 <apo> and for large packages just push the debian directories
15:43:52 <petn-randall> Hm, so this isn't the default yet? I'm suprised. What packages are not in git currently?
15:44:03 <el_cubano> petn-randall: Pretty much all of them
15:44:06 * ta agrees with apo
15:44:19 <bunk> What do we gain compared to just having the Debian packages as tarballs?
15:44:22 <el_cubano> are not in Git, that is (except for some where the maintainer or team has them in Salsa and we know about it)
15:44:55 <buxy> bunk: we get some history that we are lacking currently
15:45:07 <apo> bunk: we don't have history for our ELTS packages right now. There is no way to download previous ELTS versions
15:45:15 <apo> like with snapshot.debian.org
15:45:27 <bunk> Wouldn't it be easier to fix that?
15:45:40 <apo> yeah, either that or doing both :)
15:46:02 <buxy> It's not easier as long as it relies on me only.
15:46:23 <bunk> If you have only debian/ in git, the upstream sources are archived nowhere.
15:46:45 <Beuc> Is there a way to just keep past uploads (e.g. keep +deb8u2 when uploading +deb8u3) ?  That would allow easy revert from clients and maintain history, at some additional storage cost
15:47:28 <bunk> Or even just have a huge partition where everything source or binary that gets installed into ELTS gets copied.
15:47:32 <Beuc> (I mean easier rollback for clients who experience a regression, I think that was one of the goals)
15:47:39 <bunk> s/partition/directory/
15:48:11 <bunk> Beuc: For that usecase git would not even help...
15:48:49 <buxy> The only easy way to achieve this would be to create daily snapshots with reprepro but it's not going to scale well IMO. Anything else will requires development and planning and tests.
15:50:01 <bunk> buxy: What are the usecases? If a usecase involves preserving old binaries, then git does not even help.
15:50:01 <el_cubano> buxy: Does the hosting provider of the ELTS archive server provide a block storage with snapshot capability (I'm thinking something like Amazon EBS)?
15:50:44 <buxy> I'm not opposed to it, but I don't want to do it, I merely want to apply the required changes to the production server.
15:51:22 <bunk> And ledger says 500 project hours available in ELTS, so budget should be available for a proper solution .
15:51:45 <buxy> bunk: I didn't start that discussion, it was Neil IIRC and he wanted to get some history about former changes while responding to a customer IIRC. So it's more the "git side" that he was interested in.
15:52:22 <bunk> This usecase feels like more like dgit than manually updating git trees.
15:53:02 <el_cubano> One very simply solution could be to update the archive server to take a debdiff between the incoming package and its predecessor and then store that.
15:53:41 <el_cubano> It would then be straightforward to reconstruct the history if needed.  Dropping it into a git repo can be done trivially on demand by whomever needs to work with that package
15:53:42 <buxy> At the same time, using git brings benefits like the CI and gladk is already importing all packages into git when he works on package so it didn't seem out of touch to harmonize the workflow.
15:54:06 <ta> there is a discussion about keeping multiple version of a package in reprepro bug #570623 ... maybe it would be enough to only keep the files?
15:55:44 <buxy> sure, but reprepro is not really maintained wrt to new features, I have a couple of open requests where I offered to pay to get them...
15:55:57 <bunk> You are getting CI if you are using the Debian maintainer git tree (if it exists) and follow whatever workflow is used there.
15:57:20 <buxy> I'm sorry but I have to go grab my son, I can't continue the discussion right now. Talk to you later.
15:57:41 <ta> buxy: as far as I understood keeping files is already possible but not putting all of them in the index files
15:58:50 <bunk> jeremiah: Can we discuss the topic broader as "ELTS archive, usecases and solutions" in a future meeting?
15:58:57 <jeremiah> Yes
15:59:37 <el_cubano> jeremiah: It might also help to kick off a discussion on the mailing list in a week or two, to make the discussion in the meeting go a bit more smoothly
15:59:57 <jeremiah> Many of us have been here for two hours - thanks to everyone for the good discussion!
16:00:05 <jeremiah> el_cubano: Yes, you're right
16:00:18 <jeremiah> FWIW we did this for this month's meeting as well.
16:00:31 <el_cubano> Yes.  I think it was quite helpful
16:00:58 <jeremiah> In general my goal is to have discussions during the month and then have the meeting be a place where we try and hammer out actions.
16:01:06 <gladk> I put all my work here, with CI, and it works fine
16:01:06 <gladk> https://salsa.debian.org/lts-team/packages
16:01:19 <jeremiah> I think we're getting there, of course there's load of info to coordinate from other teams as well
16:01:29 <petn-randall> One more thing: Can we add the meeting time to the channel /topic?
16:01:46 <jeremiah> petn-randall: Yes -- good idea
16:01:52 * bunk hopes jeremiah won't get cold turkey
16:01:56 <jeremiah> heh
16:02:16 <jeremiah> That's what we eat all the rest of the week. :-)
16:02:40 <jeremiah> Although el_cubano will be eating venison this year.
16:03:14 <jeremiah> If we there is nothing else super urgent I suggest we end for today.
16:03:32 <jeremiah> I'll create minutes from the meeting and start some threads about the topics.
16:03:49 <Beuc> thanks!
16:03:55 <el_cubano> thanks!
16:03:57 <petn-randall> So it's last Thursday 14:00 UTC?
16:04:02 <petn-randall> Thanks everyone!
16:04:04 <jeremiah> petn-randall: Yes, exactly
16:04:10 <apo> thanks, cu around
16:04:11 <Beuc> petn-randall, https://wiki.debian.org/LTS/Meetings
16:04:16 <ta> ok, have a nice day everybody
16:04:22 <jeremiah> #action create minutes from the meeting and start some threads about the topics
16:05:13 <jeremiah> Thanks again everyone.
16:05:19 <jeremiah> #endmeeting