=== Maik6 is now known as Maik
=== diddledani_ is now known as diddledani
=== bdmurray_ is now known as bdmurray
* cpaelzer lights the MIR campfire15:29
cpaelzer#startmeeting Weekly Main Inclusion Requests status15:29
meetingologyMeeting started at 15:29:33 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology15:29
meetingologyAvailable commands: action, commands, idea, info, link, nick15:29
cpaelzerPing for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage15:29
cpaelzer#topic current component mismatches15:29
cpaelzerMission: Identify required actions and spread the load among the teams15:29
cpaelzer#link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg15:29
cpaelzer#link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg15:29
cpaelzerI started early, but no rush - take your time15:29
eslermhi all o/15:30
cpaelzerbroadcom-sta is a seed change15:31
-ubottu:#ubuntu-meeting- Commit b3965da in ~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu "Seed broadcom-sta-dkms, rename for bcmwl-kernel-source"15:31
cpaelzerseems to be a rename, at least that is what is indicated15:32
sarnoldgood morning15:32
cpaelzerbut either way we can be sure that xnox knows what needs to be done, so I'd not act on it yet15:32
cpaelzer-proposed is a bit more crowded15:32
cpaelzerruby3.1 is there which is a transition that was started and the usual versioned source (no new MIR needed)15:33
cpaelzereverything else that is new I can see has MIRs or stub-MIRs15:33
cpaelzerso we will see it in the later stages of this meeting15:33
cpaelzerno need to add more15:33
cpaelzer#topic New MIRs15:34
cpaelzerMission: ensure to assign all incoming reviews for fast processing15:34
cpaelzer#link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir15:34
cpaelzerthe first is a false positive15:35
cpaelzeras someone added ceilometer to track15:35
cpaelzerthat is actually in security queue15:35
slyonI volunteer to review the log4cplus MIR (as I just handled the parent MIR today)15:35
slyonwe should assigned some team to the ceilometer component, to make it go away from our list..15:35
cpaelzerthanks for the voluntee slyon15:36
cpaelzerand yes I grabbed ceilometer and marked it incomplete15:37
cpaelzerthere are more of the printing stack which I was reviewing a bit recently15:37
-ubottu:#ubuntu-meeting- Launchpad bug 2003272 in cpdb-backend-file (Ubuntu) "[MIR] cpdb-backend-file" [High, New]15:37
-ubottu:#ubuntu-meeting- Launchpad bug 2003259 in cups-filters (Ubuntu) "[MIR] libcupsfilters libppd cups-browsed" [Undecided, New]15:37
didrocksI’m happy to take the printing ones15:38
didrocksunsure it will be fun, but meh :)15:38
joalifi can take markdown-it-py15:38
cpaelzerI'll tkae unicode15:39
cpaelzerso we all grabbed one or two already15:39
cpaelzerand BTW I've seen many of you complete their reviews of last week15:39
cpaelzerwhat is left is15:39
-ubottu:#ubuntu-meeting- Launchpad bug 2003570 in rich (Ubuntu) "[MIR] rich" [Undecided, New]15:39
-ubottu:#ubuntu-meeting- Launchpad bug 821883 in argyll (Ubuntu) "[MIR] argyll" [High, Incomplete]15:39
joalifi can take rich15:40
slyonpython-rich will be a dependency of netplan, soonish15:40
cpaelzerargyll / colord might be a false positive from tacking again15:40
cpaelzerassigning rich to joalif - thanks15:40
slyonI can investigate argyll15:40
cpaelzerOh I've just read enough of that case15:41
cpaelzerit is colord re-enabling argyll15:41
cpaelzerso the recent merge15:41
cpaelzermade it hit a mismatch15:41
cpaelzermaybe we just need to ping RAOF before we go full review?15:41
didrocksyeah, let me write on the MIR and assign to him15:41
cpaelzer#topic Incomplete bugs / questions15:42
cpaelzerMission: Identify required actions and spread the load among the teams15:42
cpaelzer#link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir15:42
cpaelzernothing new in here we didn't have under control15:42
cpaelzer#topic MIR related Security Review Queue15:43
cpaelzerMission: Check on progress, do deadlines seem doable?15:43
cpaelzer#link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir15:43
cpaelzerInternal link15:43
cpaelzer- ensure your teams items are prioritized among each other as you'd expect15:43
cpaelzer- ensure community requests do not get stomped by teams calling for favors too much15:43
cpaelzer#link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/59415:43
cpaelzersarnold: I see Mark E complete a lot, thanks to him15:43
sarnoldyes :) he's been doing great15:43
cpaelzersarnold: how do your reviews and further people joining you go on?15:43
sarnoldwe've also had good traction with the editorconfig-core upstream \o/15:43
eslermthanks, I'll be joining these meetings from now on15:43
cpaelzer13 backlog, 1 todo, 4 in progress15:44
sarnoldcpaelzer: I alas haven't started in on my most recent assigned review yet :( ccdm94 has started in on xdp-tools15:44
cpaelzerwe today assigned a bunch of MIRs I'd expect 2-3 of them to land there as well15:44
slyonisc-kea is a big one in the security queue as of today. (but "only" needed for 23.10)15:45
eslermiiuc, AlexB, Seth, and I are assigning out MIRs to other Security Team members this week15:45
cpaelzerso I'd expect at least an overall of 13+1+4+~3 = 22 for ~4 weeks15:45
cpaelzerI know in theory these can land after FF15:45
cpaelzerbut let us strive for feature freeze - if we even plan for FFEs why have it in the first place15:45
sarnoldslyon: but with such an important package it'd be nice to get more than one interim release on it before an lts15:45
cpaelzerthanks eslerm for assigning to others15:46
cpaelzerslyon: sarnold: which is what we will have 23.04 + 23.10 before 24.0415:46
sarnoldanyway, I'm feeling more optimistic than usual :)15:46
cpaelzerslyon: also kea is one of those where security will be happy as it should be better to keep secure than the alternative15:46
cpaelzerso there is extra motivation15:46
cpaelzerbtw slyon thanks for the extra hints what to look at15:46
cpaelzernone of them are blockers, but they were great to be brought up15:47
sarnoldand isc has been a good upstream for bind and ye olde dhcp packages15:47
cpaelzersarnold: ok, so I hear you and eslerm rock and you will soon have Alex and others to tackle it as well15:47
cpaelzerthat shall be enough for today I'd think15:47
cpaelzer#topic Any other business?15:47
cpaelzernothing from me15:48
sarnoldnone here15:48
didrocksnothing for me15:48
eslermsame :)15:48
cpaelzerok thank you, for discussions, for continuous reviews and for coordination here and in general15:48
cpaelzerif ever you feel bad do either of15:48
sarnoldthanks cpaelzer, all :)15:48
cpaelzera) suggest improvements15:48
cpaelzerb) remember how it was before we stepped up and have driven it this way15:48
cpaelzersee you all next week15:48
joalifthanks cpaelzer, all :)15:48
meetingologyMeeting ended at 15:49:00 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-01-24-15.29.moin.txt15:49
slyonthanks cpaelzer, all!15:49
eslermbye all o/15:49
=== genii_ is now known as genii
didrocksthanks! o/15:51
* vorlon waves19:56
amurraymorning :)19:59
amurray#startmeeting Ubuntu Technical Board20:00
meetingologyMeeting started at 20:00:57 UTC.  The chair is amurray.  Information about MeetBot at https://wiki.ubuntu.com/meetingology20:00
meetingologyAvailable commands: action, commands, idea, info, link, nick20:00
amurray#topic Apologies20:01
amurraysil2100 emailed earlier to say he couldn't make it, but everyone else is here :)20:02
amurray#topic Action review20:02
amurrayACTION: (everyone) review the Ubuntu Backports Team Charter for ratification20:02
seb128I sent an email about that on the list since I'm a bit confused by what we need to review exactly?20:03
rbasakMaybe I can try to explain my perspective now20:03
rbasakIt's been brought up in a few different places that it would be helpful to have better documentation about exactly what is delegated by TB to other teams.20:04
rbasakThe DMB, release and archive teams' "undocumented delegations" have been been brought up in the past couple of years for separate reasons.20:04
rbasakWhen we resurrected the backporters team, I thought it'd be helpful to have a similar text, and I suggested that in the original resurrection thread on ubuntu-devel@20:05
rbasakWell, the text. Not specifically that it should be formalised at I thought that premature at the time.20:05
rbasakIn time, I suggested this to the backporters team, and it turned out that they were working on some similar text.20:05
rbasakBut their (specifically ddstreet's) idea of what that should be differed from mine.20:06
rbasakThey wanted to have text to define what I consider to be their "internal" operations. IMHO, the details of how they do things should be up to them, and the TB should leave teams to "get on with it" with minimal interference. Therefore, that stuff does not need to be and should not be ratified by the TB.20:07
rbasakSo the backporters team made that page empty, and moved their internal operations documentation elsewhere.20:07
rbasakBut, I still think it would be useful to have some text that defines the team's responsibilities to the rest of the project. I think my original text is still appropriate for that.20:07
rbasakddstreet disagreed in a TB thread. I'll find the link shortly.20:08
rbasakSo that's the current status.20:08
seb128so where is your original text? and is that we need to review or does someone (who?) need to turn that into a proper document first?20:08
rbasak#link https://lists.ubuntu.com/archives/technical-board/2022-March/002620.html20:08
amurrayIs it a requirement for the backporters team to have a charter at all for them to function?20:08
rbasakHere's the original text: https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html20:09
rbasakHere's where I proposed that text to the backporters team: https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022687.html20:09
rbasakamurray: I got the impression that they preferred to have one, but I think what they wanted was IMHO more an internal thing and not a TB matter. I believe they're proceeding with their own internal documentation instead.20:10
amurrayfwiw I think that your proposed text looks quite reasonable - I recall there was some objection to things like "making sure that all requests receive an appropriate answer in a reasonable amount of time" - but I can't really understand why20:11
rbasakThe reason I want it is because I think it's a useful thing to have for all teams, and it's been an issue on a few different occasions that there isn't some text to refer to.20:11
rbasakI'd like for us to make progress in that direction, and because the backporters team resurrection was quite recent, I had that in mind and wrote it at the time, and in the original thread everyone seemed to agree with the text as I'd written it.20:12
amurrayrbasak: to allow this to try and make some headway, how would you feel if we proposed to them your text from above but without the few bits that they objected to ("reasonable amount of time" etc)?20:13
rbasakSure. I'm not sure how to do that without removing the text entirely. I'm disappointed that they seemed unable to make any kind of counterproposal or propose any edits to my text. But if we can make progress that way, then sure. I'm not precious about my precise text. But...20:15
rbasak...most of what I wrote there were specifically about what failed with the backporters team previously which led to the need for it to be resurrected.20:15
rbasakLike reviews were piling up and not being done in a reasonable amount of time - hence that bit of my text.20:15
seb128one issue is that a such statement isn't really helping in resolving the issue if that's due to lack of manpower20:16
rbasakAnd some people who happened to have suitable privilege were then bypassing the previous backports review process, which I think is really bad procedurally because I don't want to see any part of the archive becoming de-facto exclusive like that.20:17
seb128you can't really force a volunteers' based team to commit to be able to be responsive20:17
rbasakseb128: sure. but if they don't have the manpower and that means they can't meet their responsibilties, then the matter *should* be escalated to the TB to decide what needs to be done about it, and so it's entirely appropriate to identify that they aren't meeting their responsiblities. So it's right to have that in the text.20:18
rbasakBut yes, as volunteers, we can't hold them to it, and I am definitely not seeking to blame individuals should such a case arise again.20:19
rbasakTo take another example, let's say that community-contributed SRUs stopped getting processed entirely.20:20
rbasakIn favour of Canonical-priority SRUs only, with the SRU team currently happening to be entirely Canonical-staffed.20:20
rbasakThat would be a matter for the TB to intervene in, IMHO.20:20
rbasakSo it would be right for the TB to say that the SRU team has that responsibility.20:21
amurrayrbasak: sure but even if does get escalated to the TB, I am not sure there is a lot we can do about it - we are unlikely to be able to find more volunteers to get more resources for the team20:21
rbasakEven though the SRU team is currently staffed entirely by Canonical-employee "volunteers" as far as the Ubuntu project is concerned.20:21
seb128right, explained like that it makes sense to me20:21
rbasakamurray: sure. Then it'd go back to my original thread, where I proposed to acknowledge that and officially sunset the backports pocket.20:22
seb128but do we need that written down for the TB to be able to exercice that right anyway?20:22
rbasakWith hindsight, I think it would have helped.20:22
seb128I think that's a project level expectation that the TB take action to fix any of the non working teams20:22
rbasakIn the case of the backports pocket, there were multiple previous posts to ubuntu-devel@ and it dragged on for years.20:22
seb128well it would have been in the power of anyone to bring the topic to the TB20:23
rbasakHad the text been there presently, I think there would have been far less friction in a TB escalation and intervention much earlier.20:23
seb128right, it could help to make people more entitled to raise up the issue to the TB20:24
rbasakFor example, we had people volunteering to do backports review, but the backporters team admins were absent.20:24
seb128not that the lack of such statement would personally stop me, but I see how it might be different for others20:24
rbasakI think it would have been easier for those volunteers to say "look, based on this text the team weren't meeting their responsibilities, and I'm volunteering, so..."20:24
rbasakI hope that explains my reasoning.20:25
seb128thanks for the explanation, and I think that seen from that angle it makes sense20:25
rbasakAnyway, I'd appreciate any help in breaking the current impasse.20:25
rbasakBut I think it needs other TB members to get involved in that thread.20:25
amurrayyep I agree with all your points rbasak but I think we need to find some way forward here - I'll see if I can draft something which is a little less "SLA"-like and send it to the backporters team20:26
seb128I think it would help if you posted the proposal again so we have a logical/recent base to reply to20:26
rbasakamurray: please! I'd appreciate that.20:26
seb128amurray, +1 from me20:26
amurray#action amurray to propose amended Ubuntu Backporters Team Charter20:27
meetingologyACTION: amurray to propose amended Ubuntu Backporters Team Charter20:27
amurrayACTION: rbasak to finalize third-party seeded snap security policy20:27
rbasakI continue to work on this.20:27
rbasakA couple of requests.20:27
rbasakseb128: could you please help draft an exception to the "must build on all architectures" requirement for snaps in the case of non- desktop support for specific architectures? I think you might best understand what that should look like.20:28
seb128rbasak, yes20:28
seb128#action seb128 to help draft an exception to the "must build on all architectures" requirement for snaps20:29
meetingologyACTION: seb128 to help draft an exception to the "must build on all architectures" requirement for snaps20:29
rbasakAnd second, I'd like some help with writing a description of how snaps work wrt. the store and the Ubuntu-specific tracks, which I'm not sure I fully understand. In this section: https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit#bookmark=id.tbw4pletjt3g20:30
seb128I could help with that as well, unless amurray wants to do it :)20:30
rbasakThanks. What I mean for example is that for example on 22.04 firefox tracks latest/stable/ubuntu-22.04, and I think that's the mechanism that implements some of the requirements, and we should document how that occurs.20:31
rbasakMeanwhile I'll continue cleaning up the rest of the feedback. I just got stuck on those two so far.20:31
amurrayI can try help but having not used branches much before I may not be as knowledgable - but I can certainly try and propose something if needed20:31
rbasaksil2100 might also be able to help with this one, but he's not here right now.20:33
seb128#action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage20:34
meetingologyACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage20:34
amurrayhehe thanks seb (I wasn't sure on who to assign that to)20:34
seb128I will try to own it but will welcome input from you and Lukasz20:34
amurraythank you20:34
amurrayrbasak: do we still need a general action in the minutes around the policy as a whole?20:35
amurrayor do you want to wait until these two new actions make some headway?20:35
rbasakamurray: I think maybe we should have a general topic for us to discuss any blockers, and just those specific actions for now? We can clean all the others up.20:36
amurray#action rbasak to raise any on-going blockers with third-party seeded snap security policy20:37
meetingologyACTION: rbasak to raise any on-going blockers with third-party seeded snap security policy20:37
rbasak+1 thanks20:37
amurrayACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step20:37
amurraysil2100 is out so lets carry this over20:37
amurray#action sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step20:37
meetingologyACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step20:37
amurrayACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification20:37
rbasakStill pending - carry over please.20:38
amurray#action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification20:38
meetingologyACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification20:38
rbasak(I expect to carry for a while, until the third party repo requirements block on me less)20:38
amurrayACTION: amurray to figure out next steps to improve TB processes previously discussed - and to figure out what the previous discussion was about20:38
amurrayok so looking back over the history, this was raised by Fallen from the community team - wanting a way for the community to be able to follow long with the longer term work of the TB20:39
amurrayit was suggested to use a separate LP project with bugs to track each of the work items20:39
amurrayI notice there is already a techboard project on LP, and this has only ever had a single bug reported against it - so I wonder if we could just reuse that - and as far as a process for this...20:40
rbasakRight. IIRC we were all happy with that, but it needed some effort from someone to set up all the details.20:40
rbasakYeah, and that was mentioned too.20:40
amurrayMy suggestion would be to have a bug for each longer term item in the agenda - how we decide what meets this "longer term" criteria is uncertain though - but this would give a way for anyone to see what is happening more easily and to subscribe to bugs for the project etc to get notified of new items20:40
rbasakOh I didn't know about the techboard project actually20:41
rbasakWe also have https://bugs.launchpad.net/ubuntu-community/+bugs with the idea that bugs could be assigned to ~techboard. But it turns out not everyone can do that.20:41
vorlonin previous TB meeting I believe we agreed to move to a project to solve the problem of assigning bugs under ubuntu-community20:42
vorlonbut the execution was lacking20:42
rbasakI guess we could re-use the techboard project then, rather than create a new one/20:42
amurraysure, one less hurdle20:43
vorlonthat would be nice20:43
rbasakIt looks like we own it, so no ACL issues20:43
amurrayregarding the question of which items qualify for LP bug tracking, how about we said something like 'if an item is carried over more than twice then a LP bug should be created in the techboard LP project to track this work'?20:44
rbasakSounds like third party repo requirements needs tracking20:45
rbasakAs well as my DMB inactivity expiration policy item20:46
amurrayone final detail - should we stipulate that the meeting chair creates these bugs or the owner of the action item?20:47
amurray(perhaps it doesn't matter but I think making the process clear is useful)20:47
amurrayI personally prefer saying the meeting chair should, since they will already be updating the agenda wiki page20:48
seb128I would prefer the item owner, that's probably the person understand best the details20:48
seb128sorry :p20:48
rbasakI have no strong opinion.20:48
vorlonseb128's response makes sense to me20:49
rbasakIf you wanted, you could make it a separate action item - then the task could be assigned easily at the time.20:49
amurrayhehe no worries - I don't feel strongly either way either really I just prefer to have something written down, otherwise its too easier to have things fall through the cracks20:49
amurrayrbasak: do you mean a standing action item in the agenda?20:49
rbasakNo, I mean add an action like "amurray to create the <x> bug"20:50
rbasakBut seb128's answer also works, if everyone's happy with that.20:50
rbasakAnd would be less admin.20:50
amurrayyeah lets go with that20:50
amurray(ie seb128's proposal)20:50
amurray#action rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies20:51
meetingologyACTION: rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies20:51
amurrayACTION: vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed.20:52
vorloncarry-over, sorry.  I'll try to get that done this week20:52
amurray#action vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed.20:52
meetingologyACTION: vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed.20:52
* Eickmeyer is biting at the bit20:52
amurrayACTION: sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon.20:52
amurray#action sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon.20:53
meetingologyACTION: sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon.20:53
amurrayACTION: vorlon to request change of the meeting weeks for the TB meeting starting February20:53
amurrayI recall we discussed this last time?20:53
vorlonI think this was just pushed so that I wouldn't break the calendar confusingly before today's meeting20:53
vorlonso I'll push the next meeting out a week on the calendar20:53
amurray#action vorlon to push the next meeting out a week in the calendar20:54
meetingologyACTION: vorlon to push the next meeting out a week in the calendar20:54
amurrayoh thanks20:54
meetingologyRemoving item from minutes: ACTION20:54
amurray#topic Scan the mailing list archive for anything we missed (standing item)20:54
vorlonthis is why we need to get fresh blood on the TB from time to time, I had no idea there was an #undo command :P20:54
rbasakWhat, you mean you don't read the instructions you get given every time you chair? :-P20:55
amurraythe main thing here that I saw was the xubuntu minimal image announcement from vorlon - so other than now being aware of this, does the TB have to officially ack this? I thought it was more an informational thing20:55
rbasakI think we agreed it's just an informational thing.20:56
vorlonI believe the agreement was that this was informational20:56
rbasakUnless an individual TB member has any objection.20:56
amurraynice - sounds like there is no objection :)20:56
rbasak(or someone else escalates one I suppose)20:56
amurray#topic Check up on community bugs (standing item)20:57
amurraynothing new here20:57
rbasakThis standing item might need to change with the new bug system20:57
amurray#topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)20:57
rbasakBut that can wait I guess20:57
amurrayrbasak: tag you're it :)20:57
amurray#topic AOB20:57
amurraylast call?20:59
vorlonnothing here20:59
seb128nothing from me20:59
amurrayno worries20:59
rbasakNothing from me.20:59
meetingologyMeeting ended at 20:59:35 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-01-24-20.00.moin.txt20:59
rbasakThank you for chairing a very well timed meeting :-)20:59
amurraythanks folks20:59
amurrayhehe I was watching the clock :)21:00
vorlonthanks, all21:00
FallenThanks for following up on that action item about the LP project :)23:40

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!