14:00:36 #startmeeting 14:00:36 Meeting started Thu Mar 24 14:00:36 2022 UTC. The chair is jeremiah. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:36 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:45 ¡Hola! 14:01:22 * petn-randall waves. 14:01:23 hallo! 14:01:31 There's big agenda apparently, let's just start. 14:01:40 Right. 14:01:55 As a quick reminder, agenda is here: https://pad.riseup.net/p/lts-meeting-agenda 14:02:35 Let's jump to the first topic which is likely familiar to everyone, "Documentation, one place for everything." 14:02:50 Anton, did you want to add anything to your topic? 14:03:23 You wrote, " Maybe it makes sense to put everything in one place, to have just one source of information." 14:03:35 I started to work on ELTS this/last week, and it was not quite clear, where I can find a documentation about that 14:04:04 we have something in readmes, wikis (different pages) etc. From my point of view it woould be good to have just one source of the information 14:04:19 I think this is surely a good idea, but in practice it's difficult to have a single source of authoritative info. 14:04:21 The best would be - in git somewhere 14:04:46 that does make sense. I think we want to put the public bits on the wiki and the private bits on the ELTS repo. 14:04:55 We have some READMEs in Git, do you think those could be expanded into a handbook for example? 14:04:59 Also I am preparing a documentation about DEP-14/ELTS-archive etc and the question is, what is it the best place to keep it? 14:05:17 wiki, perhaps. Because it can be public? 14:05:24 yes, maybe something like a handbook 14:05:43 it should be as simple as possbile and each of us should know, where it read it and where to update it 14:06:28 but we have to think, that some parts of it should be keep in secret 14:06:43 I think that if we were to expand the READMEs or at least to start from them, that might be the expected place for those new to LTS / ELTS to start. 14:06:54 My proposal is to have something like set of md-file (basially we have a plain text almost everywhere) 14:07:05 We started with the wiki as the official place to document the LTS team but it was before we had the salsa lts-team group. There's also the possibility to use gitlab pages to build some website dedicated to the team there. 14:07:30 What about a documentation index that is kept in Git. It can simply list places where things are documented. Entries can be added/removed as things change. 14:07:44 @buxy you have an experience about writing handbooks (as far as I know).... 14:07:58 I'd like if things can are available publicly - not everything but as much as we can put it out there. 14:08:41 Yes, I agree with Utkarsh. But we still have some secret things or "not-public" things 14:08:52 I think having things public is consistent with the stated desire to be transparent. 14:08:55 gladk: heh, when the documentation becomes a bit big and needs some structure, I like to use sphinx to generate proper documentation 14:09:24 eg things like https://qa.pages.debian.net/distro-tracker/ built out of git repositories 14:09:43 I do think Markdown that can be turned into web pages and kept in a git repo is also useful as a single source of truth and would match both the expected and existing workflow. 14:09:50 putting things together in a git and forming a handbook isn't bad either; cf: https://github.com/canonical/ubuntu-maintainers-handbook/, for example. 14:10:00 I don't know if it's required here but it's a possibility. 14:10:36 s/git/git repository/g :) 14:10:54 I note that our README in debian-lts is 309 lines long already. 14:11:57 I'm afraid that freexian specific parts will have to stay there. But we could structure it like the example that utkarsh2102 gave 14:12:08 So, what conclusion do we have from discussion? Should we put everything in git and then try to render it somehow? 14:12:28 I'm positive to that suggestion gladk 14:12:45 And to leave wiki only for some "user information"? 14:12:52 I can help once the survey bits are done! 14:13:02 Well, it's not clear what the underlying issue was... when you described it it sounded like more you were not able to find relevant documentation for the ELTS workflow. 14:13:03 user very short information? 14:13:25 * bhe[m] joined late. Going through back logs. 14:13:34 @buxy, it is true. I had some problems to find how to prepare an upload into ELTS 14:14:11 then I found it in readme in security tracker (I think), though for LTS we have everything in git. 14:14:23 *in wiki, 14:14:32 So maybe we need to expand the documentation in our internal extended-lts git repository. Can you take care of that? 14:15:22 You mean in our forked security tracker? I thought that the few things that we have are in gitlab.com/freexian-lts/extended-lts 14:15:26 Yes, maybe. But the idea is also to have just everything in one place to point newcomers into it. 14:15:47 I would expect this repository to be the entry point to new ELTS contributors. 14:16:01 @buxy, maybe.... not sure now. need to check. I do have a restricted internet access now. But anyway, it was no t in wiki 14:16:41 That's sure. ELTS is entirely separate. 14:16:45 My first ELTS upload was successful, but I had doubts, whether I am doing everything proper 14:17:29 That points to the underlying issue then being that the documentation is both hard to find and not complete. 14:18:07 In any case, I think it's a good idea to keep the wiki for user-relevant information and create a dedicated place in salsa.debian.org/lts-team to host the contributor documentation. 14:18:50 @jeremiah, I think we create one-more issue with the nice summary and then we will try to work on it 14:18:58 summary from buxy 14:19:21 #action Jeremiah - create new issue with summary for documentation in ELTS 14:19:27 :) 14:20:05 If we' 14:20:16 re good here, I suggest we move on to the next topic. 14:20:37 Sorry for the spurious linefeed. 14:21:17 The next topic is "Ensure we are ready to support Debian 8 and Debian 9 in parallel in ELTS" 14:21:18 I agree 14:22:09 Supporting Debian 8 and 9 in parallel has implications. 14:22:33 Hopefully we can outline all of them. 14:22:34 fwiw, the issue link is private. :D 14:22:49 Jeremiah, could you please post the whole text here? 14:22:53 Sure. 14:22:55 if it is possible 14:23:14 Starting in July 2022, we will have to support Debian 8 and Debian 9 in parallel as part of ELTS. We need to make sure that everything is ready for this 14:23:32 - the paid contributor's ELTS repository need to work with more than one list of packages to support 14:23:41 - the website needs to be enhanced so that an ELA can document updates to multiple releases at once 14:23:50 - the internal ELTS documentation needs to reflect the changes 14:23:59 - various scripts might have to be adapted 14:25:00 I think it'd be helpful to create different issues with the above points and flag them as high priority and someone can just take a look and work on it? 14:25:00 Internal workflows will be handled by Freexian, but the ELTS team will have to help me ensure that we've not forgotten anything and to document changes. 14:25:16 utkarsh2102_: That seems like a useful approach. 14:25:28 I agree also 14:25:42 I'd like to be able to assign people the issues if we do go down that path. 14:26:27 And I'd need to get input from folks who know the workflow well. 14:26:31 Can you identify other possible issues? I wrote the above on the top of my head but I might have missed stuff. 14:27:48 can this be transferred to a repository which is not internal to Freexian? either way is fine, though. But if others were to contribute, I think it'd help if people can access the meta-issue in the first place. 14:28:42 We can duplicate a meta-issue in the freexian-lts group. But I'd like to keep one as well. 14:28:44 I'd like to keep this issue where it is, but pull out those topics which can be easily made public. 14:29:03 of course, sure thing! 14:29:28 I do think the issue at the moment is to ensure that we are as exhaustive as possible in understanding what the implications of two Debian versions in ELTS is. 14:29:49 And I think that the "you" in buxy's statement was meant for all of us (just for the sake of clarity.) 14:30:10 At least all those who are contributing to ELTS. 14:31:07 I assume that there will be more work - will folks have to adjust their hours? 14:31:50 ELTS contributors tends to have unused ELTS hours, they can request more if they need though 14:32:02 Ok 14:33:35 Hopefully some of the triage/investigation work across Debian 8 and 9 will be quite similar or pretty much analagous. 14:33:57 #action jeremiah to create issues in freexian-lts/extended-lts to share the work to prepare for supporting Debian 8 and 9 in parallel 14:34:17 I think one need to plan next months less DLA-ELAs and do some issues-work... 14:34:29 I'll also keep this topic on the agenda going forward. 14:35:31 Apropos DLAs and ELAs, the next topic is "Possible merge of dla-needed and ela-needed?" if we're ready., 14:36:16 If there is no further discussion on parallel support for 8 and 9, perhaps Anton you would like to kick off this new topic? 14:36:44 You asked in the agenda if it was possible to merge dla-needed and ela-needed 14:36:45 Yes, the question with this topic is that we have a lot of duplications in ela-needed and dla-needed. Maybe it makes sense to merge it like it is done with stable and oldstable? 14:36:48 #topic Possible merge of dla-needed and ela-needed? 14:37:11 Whilst that's possible but if we don't have a sane reason for that, I don't think we should do that. 14:37:33 The whole thing would become unnecessarily complex and complicated, esp. with two parallel ELTS versions. 14:37:34 We have even sometimes collisions, when the one person is starting to work one issue in LTS, and another person takes the same CVE for ELTS 14:37:54 But that is okay, right? 14:38:03 They are not managed in the same repository so I don't really how it would be possible. It's a bit like the story of ELTS frontdesk. We don't want to impose LTS contributors to follow ELTS. 14:39:12 OK, that is the same history with a subset of contributors in ELTS, which seems to be now the same. 14:39:18 LTS=ELTS now? 14:39:40 Even though we work on both ELTS is still not part of Debian. So merging dla-needed and ela-needed is not good 14:39:44 Well, it was just a sugestion to discuss. If it works - ket;s not break it :) 14:39:52 I think it is a good idea to allow LTS to be a separate domain so that folks may chose to work just on LTS. 14:40:29 and the security team is definitely not going to like the jessie bits in the main security tracker. 14:41:50 I'll move on to another topic if we're ready. 14:42:22 #topic Improve publication of DLAs -- who's responsible? 14:42:42 There have been some questions about our policy 14:43:14 Is it the person who does the upload who is responsible for publishing the DLA / ELA? 14:44:02 It's my understanding that this is the policy. 14:44:33 Yes according to https://wiki.debian.org/LTS/Development#Prepare_an_update_for_the_website 14:44:40 that's correct, see https://wiki.debian.org/LTS/Development#Prepare_an_update_for_the_website 14:44:45 aah, buxy was faster :) 14:44:54 That is consistent with my understanding as well. 14:46:21 With that clarification in hand, there is still improvement to the process as an issue. 14:46:34 yeah that's the current practice 14:47:19 Issue #6 in the lts-extras-tasks list improvement of the publishing process for DLAs, specifically to the web site. 14:47:47 Brian May had some good input here and I wonder how we can push this forward? 14:47:58 The publication of updates to the website could be monitoried by a service that is subscribed to the announcement list and then periodically (daily?) checks to ensure that all new announcements are published to the website? 14:48:20 jeremiah: I'll take a look at the issue and consider adding my suggestion there if it makes sense. 14:48:27 Hmm, that sounds promising. 14:48:46 #action el_cubano review the issue and suggest an approach 14:49:28 el_cubano: You captured a lot of background info on the topic in the issue as well 14:49:38 Which is a Good Thing. 14:50:18 I think that topic is mostly complete - I'll move on. 14:50:34 #topic Progress of "Archiving of ELTS packages" 14:50:52 More work done by Anton 14:50:53 Somehow I have the feeling that we should commit something structured in a git repository under our own control and we should use that to generate the emails we send out and to auto-update the website without requiring all of us to have commit privileges. 14:51:19 (but that's food for thoughts for el_cubano :-)) 14:51:48 buxy: By "emails we send out" are you referring to the messages that go to debian-lts-announce? 14:51:57 Yes. 14:52:18 Regarding Archiving... That is more-less status update. I have moved all repos according to DEP-14, most of packages are having CI-checks. 14:52:25 Interesting. I'll make sure to include that as a possibility it it isn't already captured. 14:52:45 I wanted to start with the documentation and then.... Issue #1 14:53:19 el_cubano: I captured that in the issue. 14:53:42 Sorry, I didn't wait long enough to move on to the next topic and we've intertwined two topics. 14:54:19 gladk: This is a bit of a grey area, in this case I think that we want to have the same workflow for LTS and ELTS and so this should be recommendation in the LTS documentation IMO. 14:55:09 Yes, I agree. That would be the same for both LTS and ELTS. 14:56:49 #info The branches of all 42 projects in lts-team/packages were migrated this week to match the DEP-14 Schema. CI is setup for many projects (stretch only). 14:57:17 #action gladk will enhance LTS documentation (wherever they end up being) to include the recommendation to use git 14:57:24 Oh nice, I didn't see that. :) 14:57:46 _42_ projects. Nice. 14:58:13 #link https://salsa.debian.org/lts-team/packages 14:58:32 gladk: In the LTS README I added yesterday a short notation on git usage as well as the preference for DEP-14. 14:58:51 If you'd like to expand that or rewrite it please feel free. 14:59:01 @jeremiah, thanks! OK, I will do less CVE-work in April and will try to work on issues 14:59:10 Terrific. 15:00:04 last topic? 15:00:15 #topic Debian Developers' Survey 15:00:29 Utkarsh I believe has an status update 15:00:34 yep. 15:00:56 to start off with, I think we have delayed this already and I'd like to get this out soon now. 15:01:23 when I say "we", it was mostly me, who got sick last month. So apologies for that. 15:01:51 Glad to see you're feeling better. 15:02:17 but OTOH, it's mostly ready, I had asked Jeremiah to take a look once. And the mutual understanding is that it's ready for rolling it out to the paid contributors first and then sending it to the rest of the DDs. 15:02:27 cool, looking forward to that. 15:02:42 Do you think we should pick a date for release? 15:02:57 Are there any other blockers before sending it out that I can help with? 15:03:02 the survey.d.net service has been going down often - it went down earlier today and Laura said she'd like to update that over the weekend if that's plausible. 15:03:23 We should certainly draft an announce to be sent to debian-devel-announce. 15:04:28 so date-wise, I think we'll do the instance upgrade over the weekend and roll this out on 29th for the paid contributors, if everything works out well, we can go fully live 1st/2nd of April. 15:04:37 does that look sane enough? 15:04:48 let's avoid april 1st please... 15:04:52 heh 15:04:59 ahaha, okay 15:05:04 lol 15:05:19 how about 04th April? 15:05:38 I suppose that's a useful target date. 15:05:49 Looks good to me. 15:05:51 that's a Monday, too, so.. :) 15:06:17 We are reliant on the draft announcement and updates to the survey site being done first, which I'll note in the issue. 15:06:42 What makes survey.d.net unreliable? Are you sure that the upgrade will help? 15:06:54 cool, I have one thing that I am honestly not sure about though, which is, how are we finally going to send it to all the DDs? 15:07:15 can we rather put the survey link in d-private@l.d.o instead? 15:07:27 instead of going through the token hassle? 15:07:30 utkarsh2102: I answered that question in the ticket 15:08:03 Sorry, guys, I have to leave. I will read notes later. 15:08:09 you should configure it to be open for registration, when someone comes to the link, they enter their email and they get their tokenized link by email 15:08:24 gladk: Ok, thanks! 15:08:25 buxy: the instance is reliable but I am not sure why'd it go down a couple of times. The upgrade to LS 3.x was long due, so it'll only help, I guess. 15:08:40 buxy: ok, I'll look it up and follow through on that. 15:09:09 with that process we have verified emails and we can filter to keep only @debian.org and we will ask DD to use their debian email 15:09:47 alright, sounds good. 15:10:32 (and to be extra picky you should exclude people who have a @debian.org and who are not DD) 15:10:48 I know we're overtime but I do have a quick, last question though. With all the things happening on MLs (debates, discussions, et al), do you think rolling out the survey right now is the right time? :) 15:11:01 #action jeremiah capture remaining work to be done before publishing survey in a survey issue. 15:11:22 Yes, I think it is the right time. 15:11:43 I have a fear that not a lot of people will participate, but maybe that's just me. 15:11:53 alright, then. Thank you, jeremiah. :D 15:12:04 I hope that more will participate because of the discussion 15:12:20 Improving Debian is always a hot topic. 15:12:37 utkarsh2102_: what's your worry? It could usefully complement the leader vote and debates :) 15:12:50 there's a bunch of stuff going on d-private, too, so that's there. :) 15:13:55 I don't know how much of I can mention that here, but those who read d-private, d-devel, d-project would know what I mean. 15:14:13 but all good, we're ready to roll this out and we have a date. We'll stick to it! 15:14:45 Cool. 15:14:46 in any case, we will keep the survey running for a long time and we will send a few followup call for participation so hopefully we will have decent coverage 15:15:30 sweet, sounds good! 15:15:56 who's going to make a draft for the announce? and who will send it? 15:16:12 I'll be happy to. 15:16:46 #action Utkarsh to draft announcement for survey 15:16:59 great, I'd welcome review via https://salsa.debian.org/freexian-team/misc-drafts/-/tree/master/2022-dd-survey like we did last time 15:17:11 so if you can push your proposal there it's great 15:17:37 sweet, I'll do by the end of the month. 15:18:06 Thanks. 15:18:10 :) 15:18:11 #topic AoB 15:18:20 Any other business? 15:18:33 None here... 15:18:49 nothing from me 15:18:55 none here, either. 15:19:01 None here as well. 15:19:02 dito 15:19:09 nope 15:19:38 no 15:19:43 In which case I will say thank you to everyone for joining and for the discussion. 15:19:55 thank you, everyone. Have a good time! \o 15:20:06 #endmeeting