| === bigpod9 is now known as bigpod | ||
| === doko_ is now known as doko | ||
| === genii-core is now known as genii | ||
| cpaelzer | hiho | 14:31 |
|---|---|---|
| cpaelzer | prepping the meeting ... | 14:31 |
| ddstreet | o/ | 14:32 |
| * ddstreet in other meeting as well, so only please ping me if needed | 14:32 | |
| cpaelzer | no | 14:32 |
| cpaelzer | np | 14:32 |
| cpaelzer | #startmeeting Weekly Main Inclusion Requests status | 14:32 |
| meetingology | Meeting started at 14:32:59 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 14:32 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 14:33 |
| cpaelzer | d_dstreet is here | 14:33 |
| cpaelzer | also pinging sarnold doko didrocks jamespage | 14:33 |
| cpaelzer | we know a few are unavailable this week | 14:33 |
| cpaelzer | so I'm almost expecting a status-monologue | 14:33 |
| cpaelzer | 1. no previous actions | 14:33 |
| cpaelzer | #topic current component mismatches | 14:33 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 14:33 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 14:33 |
| cpaelzer | not seeing sarnold here :-/ | 14:35 |
| cpaelzer | I wanted to ask about the timing of https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1927004 since we close in on feature freze | 14:35 |
| ubottu | Launchpad bug 1927004 in fence-agents (Ubuntu) "[MIR] fence-agents" [Undecided, Confirmed] | 14:35 |
| cpaelzer | I'll ask in the seucrity channel instead | 14:35 |
| cpaelzer | done | 14:36 |
| doko | o/ | 14:36 |
| cpaelzer | hi doko, nice to see you | 14:36 |
| cpaelzer | everything else in these lists is known or false-positives | 14:36 |
| cpaelzer | #topic New MIRs | 14:37 |
| 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 | 14:37 |
| cpaelzer | egl-wayland is on ddstreet - he had requirements and we need to check if all are fulfilled | 14:37 |
| ddstreet | cpaelzer that's the one waiting on the q about missing tests | 14:37 |
| cpaelzer | one in particular is testing on special HW which we usually prohibit - ddstreet was so kind and suggested to put a formal "what if we need special HW for tests" in the MIR process | 14:38 |
| cpaelzer | I think we are not enough people to discuss that statement for our process | 14:38 |
| cpaelzer | but doko if you and I could read the case for 3 min and ack/nack if that is ok | 14:38 |
| cpaelzer | see the ping above it is about us saying "missing tests" and the owning team saying "can't be done in build/autopkgtest" | 14:39 |
| cpaelzer | generally I think that is ok | 14:39 |
| * cpaelzer is reading | 14:39 | |
| doko | is ubuntu-x-swat a team that we recognize? | 14:40 |
| cpaelzer | we said no to that in the past | 14:40 |
| cpaelzer | ddstreet: yeah this case has my ack in regard to the tests - here a build/autopkgtest (while nice) just isn't feasible | 14:40 |
| cpaelzer | we said no to ubuntu-x-swat I mean | 14:40 |
| doko | right, the hardware tests don't work. can we add a requirement that somebody has checked this locally? | 14:40 |
| cpaelzer | it needs to be a canonical-team as that is who offers the "support" | 14:40 |
| cpaelzer | doko: excatly, in the past we had this on dpdk and there we (server team) confirmed that we have a machine with special HW and regularly doing tests | 14:41 |
| cpaelzer | something like that I'd put into the formal MIR requirements | 14:41 |
| doko | sounds ok for me | 14:41 |
| cpaelzer | but when we have more people here to vote | 14:41 |
| cpaelzer | doko: does it have a real team subscriber as well or only ubuntu-x-swat | 14:42 |
| doko | which probably isn't going to work this week | 14:42 |
| doko | no other team subscriber | 14:42 |
| cpaelzer | I'm updating the case then | 14:43 |
| ddstreet | should the case go back to owned by me, waiting on further discussion in later mir team mtg? | 14:43 |
| cpaelzer | ddstreet: no it goes to seucrity IMHO | 14:45 |
| cpaelzer | the subscription can be solved while waiting for them | 14:45 |
| ddstreet | ack sounds good | 14:45 |
| cpaelzer | updated | 14:46 |
| cpaelzer | #topic Incomplete bugs / questions | 14:46 |
| 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 | 14:46 |
| cpaelzer | nothing since last week | 14:46 |
| cpaelzer | doko: I fail to remember which one, but IIRC some case was assigned to you and still open | 14:46 |
| cpaelzer | doko: are you aware which one or do I need to check logs? | 14:47 |
| cpaelzer | and if you are aware could you link it and estimate when it will be done (a MIR review IIRC) ? | 14:47 |
| cpaelzer | while we look for that we enter the next section | 14:47 |
| cpaelzer | #topic Any other business? | 14:47 |
| doko | urgh, don't remember which one | 14:47 |
| doko | was this some fuse stuff? | 14:48 |
| cpaelzer | no, that was a different case | 14:48 |
| cpaelzer | let me check | 14:48 |
| cpaelzer | doko: https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/1936907 ? | 14:50 |
| ubottu | Launchpad bug 1936907 in adsys (Ubuntu) "[MIR] ADSys" [Undecided, New] | 14:50 |
| cpaelzer | I think that was what didrocks waited on | 14:50 |
| cpaelzer | anything else for today ? | 14:50 |
| doko | ok | 14:51 |
| cpaelzer | ddstreet: we will have to remember about adding a statement for the special-HW testing for when more MIR members are available | 14:51 |
| cpaelzer | ok - if there is nothing else I'd close for today | 14:51 |
| cpaelzer | thanks doko and ddstreet for not letting me alone here :-) | 14:51 |
| cpaelzer | #endmeeting | 14:51 |
| meetingology | Meeting ended at 14:51:53 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-08-17-14.32.moin.txt | 14:51 |
| === bigpod9 is now known as bigpod | ||
| mdeslaur | \o | 18:59 |
| rbasak | o/ | 19:01 |
| * vorlon waves | 19:02 | |
| mdeslaur | so, looks like we're july 27th and I'm chairing | 19:04 |
| mdeslaur | is 3 quorum? | 19:04 |
| cyphermox | o/ | 19:05 |
| vorlon | we've treated 3 as quorum in the past; but now we're 4 anyway :) | 19:05 |
| mdeslaur | hi cyphermox | 19:05 |
| mdeslaur | ok. let's get this road on the show | 19:05 |
| mdeslaur | #startmeeting | 19:05 |
| meetingology | Meeting started at 19:05:43 UTC. The chair is mdeslaur. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 19:05 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 19:05 |
| mdeslaur | [topic] Apologies | 19:05 |
| mdeslaur | no apologies | 19:05 |
| mdeslaur | [topic] Action review | 19:06 |
| mdeslaur | "Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. " | 19:06 |
| mdeslaur | Wimpy ^ | 19:06 |
| mdeslaur | I'm trying to remember, didn't someone volunteer to get in touch with the mate team about that? | 19:07 |
| rbasak | I did manage to speak to Martin very briefly on IRC | 19:07 |
| mdeslaur | did anything come out of it? | 19:08 |
| * rbasak is looking for the log | 19:08 | |
| rbasak | Can we come back to it in a moment? | 19:08 |
| mdeslaur | sure, let's move on in the meantime | 19:09 |
| mdeslaur | orlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. | 19:09 |
| mdeslaur | whoops | 19:09 |
| mdeslaur | s/orlon/vorlon/ | 19:09 |
| vorlon | carry over | 19:09 |
| mdeslaur | and "vorlon to reply to seeded snap upload permissions question on list " | 19:09 |
| vorlon | fwiw there are some developments that suggest we might get some more work done on it soon, as firefox is moving to a snap | 19:09 |
| mdeslaur | ok | 19:10 |
| mdeslaur | "sil2100 to start a draft summarizing the OEM archive portion of the meeting which xnox and TB will review, edit, and ratify before we move on to figuring out the next step " | 19:10 |
| vorlon | so I suspecct I will have fewer excuses for it not getting my attention | 19:10 |
| mdeslaur | he's not here, so let's carry that one over | 19:10 |
| cyphermox | vorlon: it's long carried over, will that move as well, pushed by firefox (rebuildability) ? | 19:10 |
| vorlon | cyphermox: I think so | 19:11 |
| cyphermox | ack | 19:11 |
| mdeslaur | "rbasak to follow up regarding security-team's advice on the flatpak TB request " | 19:11 |
| rbasak | I did request the security team's input | 19:11 |
| rbasak | Not had a reply | 19:11 |
| mdeslaur | hrm, I think seth discussed it, but I don't think he officially answered...he's on vacation this week, so let's wait | 19:12 |
| mdeslaur | "Work on getting a set of requirements for Ubuntu packages that enable third party software repositiories by default - related to a ML entry " | 19:12 |
| vorlon | was this a group action? | 19:13 |
| vorlon | I hadn't seen any mailing list replies after my belated one | 19:13 |
| vorlon | not sure if I killed the mood by pointing out he's better off repackaging as a snap than waiting for a flatpak policy? | 19:14 |
| rbasak | IIRC, at a previous meeting we concluded that we (the TB) could come with a set of requirements and communicate it back | 19:14 |
| rbasak | And we started working on that on the pad | 19:14 |
| vorlon | ah right | 19:14 |
| mdeslaur | I think vorlon captured the main criteria that really is the first step, which is "one thing we have been consistent about in | 19:15 |
| mdeslaur | the past when enabling additional repositories by default in flavors has | 19:15 |
| mdeslaur | been maintaining Canonical as a single root of trust" | 19:15 |
| rbasak | I've found the log about MATE/Boutique when we're ready | 19:16 |
| rbasak | I think it'd be helpful to enumerate the requirements still | 19:16 |
| cyphermox | I will have an AOB item later | 19:16 |
| mdeslaur | I don't think there's any reason to work on more criteria if that first one can't be met by DisplayCal | 19:16 |
| rbasak | Maybe, as a compromise, we could summarise the other points raised, but make it clear that they aren't ratified? To provide an idea of what might be required, but to save us the effort of continuing if DisplayCal isn't going to meet them anyway. | 19:18 |
| mdeslaur | I'd be ok with that | 19:18 |
| mdeslaur | cyphermox, vorlon: thoughts? | 19:19 |
| cyphermox | well I agree on preparing a set of requirements ahead of time even if they're not firmed up | 19:21 |
| cyphermox | basically, getting the discussion rolling | 19:21 |
| rbasak | https://pad.ubuntu.com/third-party-repository-requirements is what we have right now | 19:21 |
| cyphermox | yup | 19:21 |
| rbasak | I think a couple of those requirements aren't currently met for snaps | 19:21 |
| rbasak | "Proposed requirement: the package is maintained by someone with Ubuntu developer membership" - not a requirement for chromium snap maintenance I think? | 19:22 |
| rbasak | and "behaviour will remain "stable" for the lifetime of an Ubuntu release. It is not to be on a "rolling release" from the users perspective" contradicts a statement at https://wiki.ubuntu.com/UbuntuSeededSnaps | 19:22 |
| mdeslaur | which statement does that contradict? | 19:25 |
| cyphermox | behavior remaining stable; typically that meant no new features for debs | 19:27 |
| rbasak | The Snap Store ecosystem empowers snap publishers to make their own decisions about how and whether to backport security fixes to stable releases vs. updating the package in the channel to a new upstream version. We accept this model as well for installed-by-default snaps, with the understanding that the publisher of each of these snaps is expected to deliver a good experience to their users." | 19:27 |
| mdeslaur | that same page also says "Including software in the default install of Ubuntu implies a certain commitment to handle upgrades cleanly and to provide continuity of behavior across updates within the stable release." | 19:28 |
| rbasak | FWIW, that page isn't ratified either | 19:28 |
| rbasak | (AIUI) | 19:28 |
| rbasak | It would be nice IMHO to get this all properly squared off. | 19:29 |
| rbasak | More important now that community members might feel that they don't have agency in the project by being measured differently for what they want to achieve. | 19:29 |
| rbasak | (with a real world request, rather than a hypothetical) | 19:30 |
| vorlon | rbasak: "maintained by someone with Ubuntu developer membership" - yes, I don't think that had come up in those specific terms in the past when talking about snaps; we had talked about ensuring there was a path for the community to take over, but that where upstreams were maintaining app packages they should have autonomy | 19:31 |
| mdeslaur | my thought there was that the package would be maintained by someone who has a vested interest in Ubuntu...if someone is maintaining a snap or a flatpak and doesn't care about testing it on Ubuntu, I don't see how we could possibly use it | 19:32 |
| vorlon | likewise, regarding "stability": the vision here was that we enable easy and secure delivery of the upstream experience, even where that differs from traditional Ubuntu SRU standards | 19:32 |
| mdeslaur | requiring developer membership seemed like an appropriate requirement to me | 19:32 |
| mdeslaur | so I think it's going to take a while to come up with requirements we all agree with...meanwhile, we have someone waiting for DisplayCal | 19:33 |
| vorlon | mdeslaur: if this is an upstream development team who maintains the package collectively, based on the view that snaps or flatpaks are a way to deliver their software to the entire Linux ecosystem without having to deal with individual distributions (which is basically the sales pitch for both of these packaging formats), what would be the expectation here? Ubuntu developer membership for each | 19:34 |
| vorlon | member of the upstream team? | 19:34 |
| mdeslaur | I don't know | 19:35 |
| vorlon | ok | 19:35 |
| mdeslaur | I don't think requiring ubuntu membership is reasonable for an upstream | 19:35 |
| mdeslaur | but then again, I don't think having upstreams deliver their software directly to users is reasonable either, so what do I know :) | 19:35 |
| mdeslaur | I just don't want us to seed something that the packager is going to respond "I don't care about ubuntu" to any issue that comes up | 19:36 |
| rbasak | That seems reasonable. | 19:38 |
| mdeslaur | In this particular case, unless I'm mistaken, the person requesting that DisplayCal be seeded isn't the packager, so how do we make sure the packager there is even interested in making sure Ubuntu is a first-class citizen | 19:39 |
| rbasak | To make progress, I wonder if we can split the proposed requirements into a few categories. | 19:39 |
| rbasak | Some we might agree unanimously | 19:39 |
| vorlon | well, from my perspective flathub as a whole is a non-starter, so then what | 19:40 |
| rbasak | Some I think contradict UbuntuSeededSnaps, and so I think are either invalid or need adjusting or UbuntuSeededSnaps, so whichever way cannot be ratified by us right now | 19:40 |
| rbasak | Some I think we don't necessarily agree on ourselves | 19:40 |
| cyphermox | why does it need to be seeded in the first place? what does it solve that can't work by someone installing it on their own if it's available? | 19:40 |
| rbasak | vorlon: I don't think that we can use your statement as-is. Is it worth going through five whys, or not? | 19:41 |
| rbasak | cyphermox: I think Eickmeyer's position is that it's important that it's there on Ubuntu Studio by dfeault | 19:41 |
| vorlon | rbasak: which statement? the one on the mailing list? | 19:41 |
| mdeslaur | I think one of the categories can be "Default repositories" | 19:41 |
| rbasak | vorlon: "from my perspective flathub as a whole is a non-starter" | 19:42 |
| vorlon | rbasak: because it's an additional root of trust | 19:42 |
| rbasak | mdeslaur: I think that's a second dimension | 19:42 |
| Eickmeyer | rbasak: It would be nice (recently had an inquery about it), and I'm running into roadblox with making a snap. | 19:42 |
| Eickmeyer | *roadblocks | 19:42 |
| rbasak | vorlon: oh, OK. So you have a separate requirement there I think. "Canonical must be the root of trust" | 19:42 |
| rbasak | I'll add that. | 19:42 |
| rbasak | Though it sort of overlaps with "must be built on infrastructure we trust" | 19:43 |
| rbasak | Let me label them | 19:43 |
| cyphermox | rbasak: I guess, but seeded packages/snap are basically a showcase of what's nice, or things that are absolutely required for systems to work. DisplayCAL is nice, but it's not necessarily useful to the vast majority of users (ie. it's good for graphics, it's not really useful if you're trying to make sound effects, music, etc.) | 19:43 |
| mdeslaur | root of trust of distribution isn't the same as where it was built | 19:43 |
| mdeslaur | those are two separate things, but related | 19:44 |
| rbasak | cyphermox: I think that's for the flavor leads to decide though. It's not really for the TB. But what we need to do is enable (by setting the expectations and requirements) flavors to be able to seed what they think is appropriate. | 19:45 |
| vorlon | rbasak: +1 | 19:45 |
| cyphermox | rbasak: oh, for sure, but I mean if you're trying to decide seeding in general vs. the case | 19:45 |
| vorlon | (that it's the flavor leads' decision) | 19:45 |
| mdeslaur | I agree with rbasak, not our decision | 19:45 |
| cyphermox | and if the publisher doesn't appear to care about Ubuntu, why should Ubuntu care about the publisher? | 19:46 |
| cyphermox | I'm not saying otherwise, I liked displaycal :P | 19:46 |
| rbasak | I think this is a pretty nuanced question. | 19:46 |
| rbasak | For example we ship calibre as a deb, contrary to upstream's desire there. | 19:46 |
| vorlon | cyphermox: I'm not sure the point you're making regaring caring | 19:46 |
| cyphermox | but calibre has Ubuntu developers preparing the package | 19:47 |
| rbasak | We presumably think it's OK because it's permitted by the licensing and we're in control of its distribution when users consume it from us | 19:47 |
| cyphermox | vorlon: I'm trying to paint the picture of having a committed maintainer for something | 19:47 |
| mdeslaur | The scenario we don,t want is to seed something and for it to stop working because the packager doesn't care about Ubuntu | 19:48 |
| cyphermox | yep | 19:48 |
| rbasak | So what I'm saying is that it meets proposed requirement B. | 19:48 |
| rbasak | But some snaps also meet proposed requirement B, and if a DisplayCal flatpak can be made to meet that requirement too, then that might be OK. | 19:48 |
| cyphermox | yes | 19:48 |
| rbasak | This might mean that it can't be shipped via Flathub | 19:48 |
| rbasak | But I don't want to dictate that. I want to specify what we need, which I think is better stated in B | 19:49 |
| mdeslaur | requirement B is the fail-safe, I want a requirement where the developer is involved and agrees that their package is going to be seeded | 19:49 |
| rbasak | mdeslaur: but we don't do that with any other deb package in the archive | 19:49 |
| rbasak | (eg. calibre) | 19:50 |
| mdeslaur | sure we do, the ubuntu developers group | 19:50 |
| mdeslaur | the debs in the archive are there because ubuntu developers agree that they should be | 19:50 |
| rbasak | OK, so if Ubuntu Studio "fork" the Flatpak package, and ship it still as a Flatpak but from somewhere else, and agree that this fork is going to be seeded, would you be happy with that? | 19:51 |
| === Droid is now known as Mekaneck | ||
| mdeslaur | oh sorry, I just noticed I said "developer" when I meant "packager" | 19:51 |
| cyphermox | how do you ensure the builds happen on trusted infrastructure? | 19:52 |
| mdeslaur | If the ubuntu studio team is taking over packaging, then yes, I'd be ok with that | 19:52 |
| mdeslaur | (assuming we had a canonical-controlled flatpak repo and build system) | 19:52 |
| rbasak | mdeslaur: define "taking over". We don't do that for packages we autosync from Debian | 19:52 |
| cyphermox | fork | 19:52 |
| rbasak | cyphermox: builds happening on trusted infrastructure is requirement F | 19:53 |
| cyphermox | rbasak: yes, I know | 19:53 |
| mdeslaur | rbasak: we "take over" packages we sync from debian | 19:53 |
| mdeslaur | rbasak: debian no longer maintains the packages in ubuntu | 19:53 |
| rbasak | I think that's a technicality | 19:53 |
| cyphermox | rbasak: I was basically saying the same as mdeslaur, "assuming canonical-controlled flatpak repo and build system") | 19:53 |
| vorlon | rbasak: fork and ship elsewhere> in principle yes, but that means getting a separate flatpak store signed by Canonical, which realistically isn't going to happen for one package, so what's the point in the end? | 19:54 |
| rbasak | What matters is that someone is committed to be able to intervene on behalf of users, without users needing to take action themselves. | 19:54 |
| rbasak | Which is requirement B, and not a separate thing | 19:54 |
| rbasak | vorlon: I'm just saying that between B and F I think we have this subthread covered | 19:54 |
| vorlon | it's good to know what our principles are, but at some point we're spending times on unrealistic generalized hypotheticals | 19:54 |
| mdeslaur | so if the packager won't fix an ubuntu-specific bug, we override the repo? | 19:54 |
| rbasak | mdeslaur: I propose that it be a requirement that this is something the Ubuntu project be in a position to do | 19:55 |
| mdeslaur | I have a hard-stop in 5 minutes, unfortunately | 19:55 |
| rbasak | Whether it happens or not is a separate matter | 19:55 |
| mdeslaur | I don't think that's enough. I think it's important that the publisher agrees that their package is seeded in Ubuntu. | 19:56 |
| rbasak | AFAICT, Ubuntu Studio would effectively be the "publisher", and so that requirement is met by default. | 19:56 |
| rbasak | There is no technical difference between that, and a fork. | 19:57 |
| vorlon | can we agree next steps? | 19:57 |
| rbasak | Because if requirement B is met, Ubuntu Studio can take over at any time, just like any deb package in universe. | 19:57 |
| mdeslaur | ok, I don't see us resolving this any time soon, each of these points is going to require discussion. | 19:57 |
| vorlon | it's a good discussion, but we're obviously not converging in 3 minutes | 19:57 |
| mdeslaur | the only thing I think we can agree to is requirement H | 19:57 |
| vorlon | (and there was an AOB item?) | 19:57 |
| cyphermox | yes, it's actually quite simple | 19:57 |
| mdeslaur | unless someone objects to H | 19:58 |
| rbasak | No objection, but I think H needs a clearer definition | 19:58 |
| rbasak | (and therefore I'm not sure about it pending that definition) | 19:58 |
| cyphermox | could we possibly put all the different threads of discussion in bugs or something so it's easier to get back state on everything here, and see progress between meetings, rather than having to re-read ML threads, find links again from IRC logs, etc.? | 19:58 |
| cyphermox | it's an idea, not necessarily the exact solution | 19:59 |
| mdeslaur | ok, so we can't respond to the DisplayCAL issue today then. | 19:59 |
| rbasak | I was hoping people would use the pad for discussion | 19:59 |
| cyphermox | not just this particular discussion | 19:59 |
| mdeslaur | so let's continue working on the pad | 19:59 |
| rbasak | (though FWIW the pad is awful and doesn't let me punctuate) | 19:59 |
| vorlon | :) | 19:59 |
| rbasak | I'd like to give others a task please. If you don't support a particular proposed requirement, please comment and explain why, to help start the discussion there | 20:00 |
| vorlon | +1 | 20:00 |
| cyphermox | aye | 20:00 |
| mdeslaur | everyone must spend some time in the pad this week | 20:00 |
| mdeslaur | ok, let's move on | 20:01 |
| mdeslaur | [topic] Mailing list archive | 20:01 |
| mdeslaur | there's the sunset backports thread, but it looks like some folks stepped up | 20:02 |
| mdeslaur | (I think that's what I read this week) | 20:02 |
| rbasak | I don't think any action is needed on that right now. It seems to be proceeding well without TB intervention and nobody has requested TB intervention to the current course of action AFAICT. | 20:02 |
| mdeslaur | ok | 20:02 |
| mdeslaur | there's rbasak's post about inconsistent password prompts in update-manager | 20:03 |
| mdeslaur | perhaps that should be a bug assigned to the security team? | 20:03 |
| rbasak | I did get the owner of ~ubuntu-backports changed to ~techboard. I assume that's uncontroversial | 20:03 |
| rbasak | Is it a bug? | 20:03 |
| rbasak | I was asking the question | 20:03 |
| mdeslaur | it's not a bug, that's the way it was designed | 20:03 |
| mdeslaur | but perhaps it should be revisited now that there are a lot more kernel updates | 20:04 |
| rbasak | I mean: is it something we need to change? | 20:04 |
| mdeslaur | when it was done that way, there were fewer kernel updates, so most updates never asked for a password | 20:04 |
| mdeslaur | I do agree that it's weird and should probably be changed | 20:04 |
| mdeslaur | or at least discussed again | 20:05 |
| rbasak | OK I can happily file a bug then | 20:05 |
| mdeslaur | IIRC, the original design was a compromise between the security team and the design team | 20:05 |
| mdeslaur | and there were technical limitations that prevented it from being smarter | 20:06 |
| mdeslaur | but perhaps it can be fixed or rethought | 20:06 |
| mdeslaur | I don't see anything else on the mailing list | 20:06 |
| mdeslaur | [topic] Community bugs | 20:07 |
| mdeslaur | none | 20:07 |
| mdeslaur | [topic] AOB | 20:07 |
| mdeslaur | cyphermox: wake up | 20:07 |
| cyphermox | ""could we possibly put all the different threads of discussion in bugs or something so it's easier to get back state on everything here, and see progress between meetings, rather than having to re-read ML threads, find links again from IRC logs, etc.?"" | 20:07 |
| cyphermox | for action items and such | 20:07 |
| rbasak | That sounds like a lot of admin. Are you volunteering? :) | 20:08 |
| cyphermox | not really, but it would be good to have things in a central location | 20:08 |
| rbasak | IOW, I have no objection to tracking things in bugs, but wouldn't that just be another place you need to read to catch up? | 20:08 |
| cyphermox | and the wiki agenda has this lack of context | 20:08 |
| mdeslaur | I thought the agenda was the central location | 20:08 |
| rbasak | Maybe discourse posts? | 20:08 |
| cyphermox | that may work too | 20:09 |
| rbasak | More editable, wiki posts are possible, etc. | 20:09 |
| mdeslaur | feel free to create discourse posts and link them in the agenda | 20:09 |
| vorlon | I don't see the point of discourse instead of bug reports | 20:09 |
| * mdeslaur needs to remember where the discourse is | 20:09 | |
| rbasak | cyphermox: honestly, I'm not sure I really understand what you're asking me to do. | 20:10 |
| rbasak | If you want to do something to help track things better, then I have no objection. But I assume you want me to then do something differently? What? | 20:10 |
| mdeslaur | I really need to leave now, so let's finish this up and cyphermox can let us know what he wants? | 20:11 |
| cyphermox | well, to me either we keep clearer action items so we remember from one time to the other what something was about, or people spend time to update them done as soon as they are, which I feel bugs would make quick -- if it's inprogress it's a carry over, otehrwise it's maybe done, etc. | 20:11 |
| mdeslaur | [topic] Next chair | 20:11 |
| mdeslaur | next chair cyphermox, backup rbasak | 20:11 |
| cyphermox | yup | 20:12 |
| mdeslaur | cyphermox: did you have another AOB, or was that what you were referring to earlier? | 20:12 |
| cyphermox | no, that's what I was referring to | 20:12 |
| mdeslaur | ok, cool | 20:12 |
| mdeslaur | #endmeeting | 20:12 |
| meetingology | Meeting ended at 20:12:52 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-08-17-19.05.moin.txt | 20:12 |
| mdeslaur | thanks everyone, apologies for having to leave | 20:13 |
| mdeslaur | I'll update the agenda tomorrow morning | 20:13 |
| * vorlon waves | 20:13 | |
| vorlon | thanks | 20:13 |
| rbasak | Thank you! | 20:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
