| === Maik6 is now known as Maik | ||
| === diddledani_ is now known as diddledani | ||
| === bdmurray_ is now known as bdmurray | ||
| cpaelzer | hiho | 15:29 |
|---|---|---|
| * cpaelzer lights the MIR campfire | 15:29 | |
| cpaelzer | #startmeeting Weekly Main Inclusion Requests status | 15:29 |
| meetingology | Meeting started at 15:29:33 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 15:29 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 15:29 |
| cpaelzer | Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage | 15:29 |
| cpaelzer | #topic current component mismatches | 15:29 |
| cpaelzer | Mission: Identify required actions and spread the load among the teams | 15:29 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 15:29 |
| slyon | o/ | 15:29 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 15:29 |
| cpaelzer | I started early, but no rush - take your time | 15:29 |
| jamespage | o/ | 15:30 |
| eslerm | hi all o/ | 15:30 |
| joalif | o/ | 15:30 |
| didrocks | hey | 15:30 |
| cpaelzer | broadcom-sta is a seed change | 15:31 |
| cpaelzer | https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=b3965da8202acba79153429b1ff36f2d7f385238 | 15: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 | |
| cpaelzer | seems to be a rename, at least that is what is indicated | 15:32 |
| sarnold | good morning | 15:32 |
| cpaelzer | but either way we can be sure that xnox knows what needs to be done, so I'd not act on it yet | 15:32 |
| cpaelzer | -proposed is a bit more crowded | 15:32 |
| cpaelzer | ruby3.1 is there which is a transition that was started and the usual versioned source (no new MIR needed) | 15:33 |
| cpaelzer | everything else that is new I can see has MIRs or stub-MIRs | 15:33 |
| cpaelzer | so we will see it in the later stages of this meeting | 15:33 |
| cpaelzer | no need to add more | 15:33 |
| slyon | ack | 15:34 |
| cpaelzer | #topic New MIRs | 15:34 |
| cpaelzer | Mission: ensure to assign all incoming reviews for fast processing | 15: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-mir | 15:34 |
| cpaelzer | the first is a false positive | 15:35 |
| cpaelzer | as someone added ceilometer to track | 15:35 |
| cpaelzer | that is actually in security queue | 15:35 |
| slyon | I volunteer to review the log4cplus MIR (as I just handled the parent MIR today) | 15:35 |
| slyon | we should assigned some team to the ceilometer component, to make it go away from our list.. | 15:35 |
| cpaelzer | thanks for the voluntee slyon | 15:36 |
| cpaelzer | and yes I grabbed ceilometer and marked it incomplete | 15:37 |
| cpaelzer | there are more of the printing stack which I was reviewing a bit recently | 15:37 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/cpdb-backend-file/+bug/2003272 | 15:37 |
| -ubottu:#ubuntu-meeting- Launchpad bug 2003272 in cpdb-backend-file (Ubuntu) "[MIR] cpdb-backend-file" [High, New] | 15:37 | |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/2003259 | 15:37 |
| -ubottu:#ubuntu-meeting- Launchpad bug 2003259 in cups-filters (Ubuntu) "[MIR] libcupsfilters libppd cups-browsed" [Undecided, New] | 15:37 | |
| didrocks | I’m happy to take the printing ones | 15:38 |
| didrocks | unsure it will be fun, but meh :) | 15:38 |
| joalif | i can take markdown-it-py | 15:38 |
| cpaelzer | I'll tkae unicode | 15:39 |
| cpaelzer | so we all grabbed one or two already | 15:39 |
| cpaelzer | and BTW I've seen many of you complete their reviews of last week | 15:39 |
| cpaelzer | thanks | 15:39 |
| cpaelzer | what is left is | 15:39 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/rich/+bug/2003570 | 15:39 |
| -ubottu:#ubuntu-meeting- Launchpad bug 2003570 in rich (Ubuntu) "[MIR] rich" [Undecided, New] | 15:39 | |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/colord/+bug/821883 | 15:39 |
| -ubottu:#ubuntu-meeting- Launchpad bug 821883 in argyll (Ubuntu) "[MIR] argyll" [High, Incomplete] | 15:39 | |
| joalif | i can take rich | 15:40 |
| slyon | python-rich will be a dependency of netplan, soonish | 15:40 |
| cpaelzer | argyll / colord might be a false positive from tacking again | 15:40 |
| cpaelzer | assigning rich to joalif - thanks | 15:40 |
| slyon | I can investigate argyll | 15:40 |
| cpaelzer | Oh I've just read enough of that case | 15:41 |
| cpaelzer | it is colord re-enabling argyll | 15:41 |
| cpaelzer | so the recent merge | 15:41 |
| cpaelzer | made it hit a mismatch | 15:41 |
| cpaelzer | maybe we just need to ping RAOF before we go full review? | 15:41 |
| didrocks | yeah, let me write on the MIR and assign to him | 15:41 |
| cpaelzer | thanks | 15:42 |
| slyon | thx | 15:42 |
| cpaelzer | #topic Incomplete bugs / questions | 15:42 |
| cpaelzer | Mission: Identify required actions and spread the load among the teams | 15: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-mir | 15:42 |
| cpaelzer | nothing new in here we didn't have under control | 15:42 |
| cpaelzer | #topic MIR related Security Review Queue | 15:43 |
| cpaelzer | Mission: 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-mir | 15:43 |
| cpaelzer | Internal link | 15:43 |
| cpaelzer | - ensure your teams items are prioritized among each other as you'd expect | 15:43 |
| cpaelzer | - ensure community requests do not get stomped by teams calling for favors too much | 15:43 |
| cpaelzer | #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 | 15:43 |
| cpaelzer | sarnold: I see Mark E complete a lot, thanks to him | 15:43 |
| sarnold | yes :) he's been doing great | 15:43 |
| cpaelzer | sarnold: how do your reviews and further people joining you go on? | 15:43 |
| sarnold | we've also had good traction with the editorconfig-core upstream \o/ | 15:43 |
| eslerm | thanks, I'll be joining these meetings from now on | 15:43 |
| sarnold | woot! | 15:43 |
| cpaelzer | 13 backlog, 1 todo, 4 in progress | 15:44 |
| sarnold | cpaelzer: I alas haven't started in on my most recent assigned review yet :( ccdm94 has started in on xdp-tools | 15:44 |
| cpaelzer | we today assigned a bunch of MIRs I'd expect 2-3 of them to land there as well | 15:44 |
| slyon | isc-kea is a big one in the security queue as of today. (but "only" needed for 23.10) | 15:45 |
| eslerm | iiuc, AlexB, Seth, and I are assigning out MIRs to other Security Team members this week | 15:45 |
| cpaelzer | so I'd expect at least an overall of 13+1+4+~3 = 22 for ~4 weeks | 15:45 |
| cpaelzer | I know in theory these can land after FF | 15:45 |
| cpaelzer | but let us strive for feature freeze - if we even plan for FFEs why have it in the first place | 15:45 |
| sarnold | slyon: but with such an important package it'd be nice to get more than one interim release on it before an lts | 15:45 |
| cpaelzer | thanks eslerm for assigning to others | 15:46 |
| cpaelzer | slyon: sarnold: which is what we will have 23.04 + 23.10 before 24.04 | 15:46 |
| sarnold | anyway, I'm feeling more optimistic than usual :) | 15:46 |
| slyon | ack | 15:46 |
| cpaelzer | slyon: also kea is one of those where security will be happy as it should be better to keep secure than the alternative | 15:46 |
| cpaelzer | so there is extra motivation | 15:46 |
| cpaelzer | btw slyon thanks for the extra hints what to look at | 15:46 |
| cpaelzer | none of them are blockers, but they were great to be brought up | 15:47 |
| sarnold | and isc has been a good upstream for bind and ye olde dhcp packages | 15:47 |
| cpaelzer | sarnold: ok, so I hear you and eslerm rock and you will soon have Alex and others to tackle it as well | 15:47 |
| cpaelzer | that shall be enough for today I'd think | 15:47 |
| cpaelzer | #topic Any other business? | 15:47 |
| cpaelzer | nothing from me | 15:48 |
| sarnold | none here | 15:48 |
| didrocks | nothing for me | 15:48 |
| joalif | nothing | 15:48 |
| eslerm | same :) | 15:48 |
| slyon | nothing | 15:48 |
| cpaelzer | ok thank you, for discussions, for continuous reviews and for coordination here and in general | 15:48 |
| cpaelzer | if ever you feel bad do either of | 15:48 |
| sarnold | thanks cpaelzer, all :) | 15:48 |
| cpaelzer | a) suggest improvements | 15:48 |
| cpaelzer | b) remember how it was before we stepped up and have driven it this way | 15:48 |
| cpaelzer | :-) | 15:48 |
| sarnold | :D | 15:48 |
| cpaelzer | see you all next week | 15:48 |
| joalif | thanks cpaelzer, all :) | 15:48 |
| cpaelzer | #endmeeting | 15:49 |
| meetingology | Meeting ended at 15:49:00 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-01-24-15.29.moin.txt | 15:49 |
| slyon | thanks cpaelzer, all! | 15:49 |
| eslerm | bye all o/ | 15:49 |
| === genii_ is now known as genii | ||
| didrocks | thanks! o/ | 15:51 |
| * vorlon waves | 19:56 | |
| rbasak | o/ | 19:57 |
| amurray | morning :) | 19:59 |
| sarnold | :) | 19:59 |
| amurray | #startmeeting Ubuntu Technical Board | 20:00 |
| meetingology | Meeting started at 20:00:57 UTC. The chair is amurray. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 20:00 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 20:00 |
| seb128 | hey | 20:01 |
| amurray | #topic Apologies | 20:01 |
| amurray | sil2100 emailed earlier to say he couldn't make it, but everyone else is here :) | 20:02 |
| amurray | #topic Action review | 20:02 |
| amurray | ACTION: (everyone) review the Ubuntu Backports Team Charter for ratification | 20:02 |
| seb128 | I sent an email about that on the list since I'm a bit confused by what we need to review exactly? | 20:03 |
| rbasak | Maybe I can try to explain my perspective now | 20:03 |
| seb128 | please | 20:03 |
| rbasak | It'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 |
| rbasak | The DMB, release and archive teams' "undocumented delegations" have been been brought up in the past couple of years for separate reasons. | 20:04 |
| rbasak | When 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 |
| rbasak | Well, the text. Not specifically that it should be formalised at I thought that premature at the time. | 20:05 |
| rbasak | In time, I suggested this to the backporters team, and it turned out that they were working on some similar text. | 20:05 |
| rbasak | But their (specifically ddstreet's) idea of what that should be differed from mine. | 20:06 |
| rbasak | They 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 |
| rbasak | So the backporters team made that page empty, and moved their internal operations documentation elsewhere. | 20:07 |
| rbasak | But, 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 |
| rbasak | ddstreet disagreed in a TB thread. I'll find the link shortly. | 20:08 |
| rbasak | So that's the current status. | 20:08 |
| seb128 | so 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.html | 20:08 |
| amurray | Is it a requirement for the backporters team to have a charter at all for them to function? | 20:08 |
| rbasak | Here's the original text: https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html | 20:09 |
| rbasak | Here's where I proposed that text to the backporters team: https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022687.html | 20:09 |
| rbasak | amurray: 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 |
| amurray | fwiw 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 why | 20:11 |
| rbasak | The 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 |
| rbasak | I'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 |
| amurray | rbasak: 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 |
| rbasak | Sure. 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 |
| rbasak | Like reviews were piling up and not being done in a reasonable amount of time - hence that bit of my text. | 20:15 |
| seb128 | one issue is that a such statement isn't really helping in resolving the issue if that's due to lack of manpower | 20:16 |
| rbasak | And 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 |
| seb128 | you can't really force a volunteers' based team to commit to be able to be responsive | 20:17 |
| rbasak | seb128: 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 |
| rbasak | But 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 |
| rbasak | To take another example, let's say that community-contributed SRUs stopped getting processed entirely. | 20:20 |
| rbasak | In favour of Canonical-priority SRUs only, with the SRU team currently happening to be entirely Canonical-staffed. | 20:20 |
| rbasak | That would be a matter for the TB to intervene in, IMHO. | 20:20 |
| rbasak | So it would be right for the TB to say that the SRU team has that responsibility. | 20:21 |
| amurray | rbasak: 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 team | 20:21 |
| rbasak | Even though the SRU team is currently staffed entirely by Canonical-employee "volunteers" as far as the Ubuntu project is concerned. | 20:21 |
| seb128 | right, explained like that it makes sense to me | 20:21 |
| rbasak | amurray: sure. Then it'd go back to my original thread, where I proposed to acknowledge that and officially sunset the backports pocket. | 20:22 |
| seb128 | but do we need that written down for the TB to be able to exercice that right anyway? | 20:22 |
| rbasak | With hindsight, I think it would have helped. | 20:22 |
| seb128 | I think that's a project level expectation that the TB take action to fix any of the non working teams | 20:22 |
| rbasak | In the case of the backports pocket, there were multiple previous posts to ubuntu-devel@ and it dragged on for years. | 20:22 |
| seb128 | well it would have been in the power of anyone to bring the topic to the TB | 20:23 |
| rbasak | Had the text been there presently, I think there would have been far less friction in a TB escalation and intervention much earlier. | 20:23 |
| seb128 | right, it could help to make people more entitled to raise up the issue to the TB | 20:24 |
| rbasak | For example, we had people volunteering to do backports review, but the backporters team admins were absent. | 20:24 |
| seb128 | not that the lack of such statement would personally stop me, but I see how it might be different for others | 20:24 |
| rbasak | I 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 |
| seb128 | right | 20:25 |
| rbasak | I hope that explains my reasoning. | 20:25 |
| seb128 | thanks for the explanation, and I think that seen from that angle it makes sense | 20:25 |
| rbasak | Anyway, I'd appreciate any help in breaking the current impasse. | 20:25 |
| rbasak | But I think it needs other TB members to get involved in that thread. | 20:25 |
| amurray | yep 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 team | 20:26 |
| seb128 | I think it would help if you posted the proposal again so we have a logical/recent base to reply to | 20:26 |
| rbasak | amurray: please! I'd appreciate that. | 20:26 |
| seb128 | amurray, +1 from me | 20:26 |
| amurray | #action amurray to propose amended Ubuntu Backporters Team Charter | 20:27 |
| meetingology | ACTION: amurray to propose amended Ubuntu Backporters Team Charter | 20:27 |
| rbasak | Thanks! | 20:27 |
| amurray | ACTION: rbasak to finalize third-party seeded snap security policy | 20:27 |
| rbasak | I continue to work on this. | 20:27 |
| rbasak | A couple of requests. | 20:27 |
| rbasak | seb128: 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 |
| seb128 | rbasak, yes | 20:28 |
| rbasak | Thanks! | 20:29 |
| seb128 | #action seb128 to help draft an exception to the "must build on all architectures" requirement for snaps | 20:29 |
| meetingology | ACTION: seb128 to help draft an exception to the "must build on all architectures" requirement for snaps | 20:29 |
| amurray | thanks | 20:30 |
| rbasak | And 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.tbw4pletjt3g | 20:30 |
| seb128 | I could help with that as well, unless amurray wants to do it :) | 20:30 |
| rbasak | Thanks. 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 |
| rbasak | Meanwhile I'll continue cleaning up the rest of the feedback. I just got stuck on those two so far. | 20:31 |
| amurray | I 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 needed | 20:31 |
| rbasak | sil2100 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 usage | 20:34 |
| meetingology | ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage | 20:34 |
| amurray | hehe thanks seb (I wasn't sure on who to assign that to) | 20:34 |
| seb128 | :) | 20:34 |
| seb128 | I will try to own it but will welcome input from you and Lukasz | 20:34 |
| amurray | thank you | 20:34 |
| amurray | rbasak: do we still need a general action in the minutes around the policy as a whole? | 20:35 |
| amurray | or do you want to wait until these two new actions make some headway? | 20:35 |
| rbasak | amurray: 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 policy | 20:37 |
| meetingology | ACTION: rbasak to raise any on-going blockers with third-party seeded snap security policy | 20:37 |
| rbasak | +1 thanks | 20: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 step | 20:37 |
| amurray | sil2100 is out so lets carry this over | 20: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 step | 20:37 |
| meetingology | 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 step | 20:37 |
| amurray | ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 20:37 |
| rbasak | Still pending - carry over please. | 20:38 |
| amurray | #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 20:38 |
| meetingology | ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 20:38 |
| rbasak | (I expect to carry for a while, until the third party repo requirements block on me less) | 20:38 |
| amurray | ACTION: amurray to figure out next steps to improve TB processes previously discussed - and to figure out what the previous discussion was about | 20:38 |
| amurray | ok 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 TB | 20:39 |
| amurray | it was suggested to use a separate LP project with bugs to track each of the work items | 20:39 |
| amurray | I 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 |
| rbasak | Right. IIRC we were all happy with that, but it needed some effort from someone to set up all the details. | 20:40 |
| rbasak | Yeah, and that was mentioned too. | 20:40 |
| amurray | My 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 items | 20:40 |
| rbasak | Oh I didn't know about the techboard project actually | 20:41 |
| rbasak | We 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 |
| vorlon | in previous TB meeting I believe we agreed to move to a project to solve the problem of assigning bugs under ubuntu-community | 20:42 |
| vorlon | but the execution was lacking | 20:42 |
| rbasak | I guess we could re-use the techboard project then, rather than create a new one/ | 20:42 |
| rbasak | ? | 20:43 |
| amurray | sure, one less hurdle | 20:43 |
| vorlon | that would be nice | 20:43 |
| rbasak | It looks like we own it, so no ACL issues | 20:43 |
| amurray | regarding 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 |
| vorlon | +1 | 20:44 |
| rbasak | Sure | 20:45 |
| rbasak | Sounds like third party repo requirements needs tracking | 20:45 |
| rbasak | As well as my DMB inactivity expiration policy item | 20:46 |
| amurray | +1 | 20:46 |
| seb128 | +1 | 20:47 |
| amurray | one 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 |
| amurray | I personally prefer saying the meeting chair should, since they will already be updating the agenda wiki page | 20:48 |
| seb128 | I would prefer the item owner, that's probably the person understand best the details | 20:48 |
| seb128 | sorry :p | 20:48 |
| seb128 | +who | 20:48 |
| rbasak | I have no strong opinion. | 20:48 |
| vorlon | seb128's response makes sense to me | 20:49 |
| rbasak | If you wanted, you could make it a separate action item - then the task could be assigned easily at the time. | 20:49 |
| amurray | hehe 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 cracks | 20:49 |
| amurray | rbasak: do you mean a standing action item in the agenda? | 20:49 |
| rbasak | No, I mean add an action like "amurray to create the <x> bug" | 20:50 |
| rbasak | But seb128's answer also works, if everyone's happy with that. | 20:50 |
| rbasak | And would be less admin. | 20:50 |
| amurray | yeah lets go with that | 20: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 policies | 20:51 |
| meetingology | ACTION: rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies | 20:51 |
| rbasak | ack | 20:51 |
| amurray | thanks | 20:51 |
| 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 |
| vorlon | carry-over, sorry. I'll try to get that done this week | 20: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 |
| meetingology | ACTION: 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 bit | 20:52 | |
| amurray | ACTION: sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon. | 20:52 |
| amurray | carry-over | 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 |
| meetingology | ACTION: sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon. | 20:53 |
| amurray | ACTION: vorlon to request change of the meeting weeks for the TB meeting starting February | 20:53 |
| amurray | I recall we discussed this last time? | 20:53 |
| vorlon | I think this was just pushed so that I wouldn't break the calendar confusingly before today's meeting | 20:53 |
| vorlon | so I'll push the next meeting out a week on the calendar | 20:53 |
| rbasak | +1 | 20:53 |
| amurray | thanks | 20:53 |
| amurray | #action vorlon to push the next meeting out a week in the calendar | 20:54 |
| meetingology | ACTION: vorlon to push the next meeting out a week in the calendar | 20:54 |
| vorlon | (done) | 20:54 |
| amurray | oh thanks | 20:54 |
| amurray | #undo | 20:54 |
| meetingology | Removing item from minutes: ACTION | 20:54 |
| amurray | #topic Scan the mailing list archive for anything we missed (standing item) | 20:54 |
| vorlon | this is why we need to get fresh blood on the TB from time to time, I had no idea there was an #undo command :P | 20:54 |
| amurray | :) | 20:55 |
| rbasak | What, you mean you don't read the instructions you get given every time you chair? :-P | 20:55 |
| amurray | the 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 thing | 20:55 |
| rbasak | I think we agreed it's just an informational thing. | 20:56 |
| vorlon | I believe the agreement was that this was informational | 20:56 |
| rbasak | Unless an individual TB member has any objection. | 20:56 |
| amurray | nice - sounds like there is no objection :) | 20:56 |
| rbasak | (or someone else escalates one I suppose) | 20:56 |
| rbasak | :) | 20:56 |
| amurray | #topic Check up on community bugs (standing item) | 20:57 |
| amurray | nothing new here | 20:57 |
| rbasak | This standing item might need to change with the new bug system | 20:57 |
| amurray | #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) | 20:57 |
| rbasak | But that can wait I guess | 20:57 |
| amurray | rbasak: tag you're it :) | 20:57 |
| rbasak | ack | 20:57 |
| amurray | #topic AOB | 20:57 |
| amurray | last call? | 20:59 |
| vorlon | nothing here | 20:59 |
| seb128 | nothing from me | 20:59 |
| amurray | no worries | 20:59 |
| rbasak | Nothing from me. | 20:59 |
| amurray | #endmeeting | 20:59 |
| meetingology | Meeting ended at 20:59:35 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-01-24-20.00.moin.txt | 20:59 |
| rbasak | Thank you for chairing a very well timed meeting :-) | 20:59 |
| amurray | thanks folks | 20:59 |
| amurray | hehe I was watching the clock :) | 21:00 |
| seb128 | thanks! | 21:00 |
| vorlon | thanks, all | 21:00 |
| Fallen | Thanks 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!
