#ubuntu-meeting-2 2014-10-14 <Riddell> is there a tech board meeting now? <shadeslayer> \o <shadeslayer> guess not <shadeslayer> Riddell: ^^ <Riddell> hum <Riddell> 16:31 < Riddell> is there a tech board meeting now? <mdeslaur> hi Riddell <mdeslaur> Riddell: infinity, pitti and stgraber can't attend <Riddell> this doesn't quite answer my question :) <mdeslaur> I'm not sure yet, if kees doesn't show up and it's just me and slangasek, we're likely to cancel it I guess <Riddell> sigh <slangasek> https://wiki.ubuntu.com/TechnicalBoardAgenda also didn't get updated, who's supposed to be chairing this week? <mdeslaur> infinity was supposed to <mdeslaur> slangasek: looks like kees isn't going to show up. Should we cancel, and respond on-list? <slangasek> mdeslaur: I think that's the way to go <slangasek> Riddell: sorry - no reason we can't still have discussions on IRC as needed, but I think there's no point in calling that a TB meeting #ubuntu-meeting-2 2014-10-28 <mdeslaur> sorry, running late <mdeslaur> ah, timezone fail * slangasek waves <pitti> hello <mdeslaur> \o <infinity> o/ * stgraber waves <kees> \o <mdeslaur> did london move, or did the time change there? :P <infinity> And the gang's all here! <pitti> mdeslaur: DST change last weekend <stgraber> mdeslaur: europe DST starts a week before north american DST <pitti> and ends three weeks after <infinity> #startmeeting <meetingology> Meeting started Tue Oct 28 17:01:27 2014 UTC. The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <pitti> (end of Oct in EU, start of Oct in US) <slangasek> strange that I didn't see anyone mentioning this DST change on lists <infinity> [TOPIC] Action review <infinity> Oh, meetingology doesn't have topic rights here, does it? Silly. <infinity> Anyhow, the one pending action is "Adam is a slacker and hasn't responded to the MAAS thing yet", so let's move on so that guy can save face. <infinity> Riddell: Are you here to discuss the two things you wanted to hit early in the meeting before you have to leave? <infinity> *tick, tick, tick* <infinity> Right, we'll leave his items until he pops up. <pitti> well, we can start the owncloud thing <pitti> which seems like a no-brainer to me <pitti> I responded to the bug and the ML <infinity> pitti: No-brainer, as in you're +1 on uploading empty packages? <pitti> yes <mdeslaur> it's quite unfortunate that nobody stepped up, but I'd rather +1 on empty packages too, rather than leaving in old crusty versions <mdeslaur> especially since upstream asked <pitti> it's ugly, but still better than leaving it vulnerable <infinity> [VOTE] replace owncloud packages with empty stubs, since no one's willing to maintain it <meetingology> Please vote on: replace owncloud packages with empty stubs, since no one's willing to maintain it <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) <infinity> +1 <meetingology> +1 received from infinity <pitti> +1 <meetingology> +1 received from pitti <mdeslaur> +1 <meetingology> +1 received from mdeslaur <stgraber> +1 <meetingology> +1 received from stgraber <slangasek> hmm <kees> +1 <meetingology> +1 received from kees <slangasek> well, I would've appreciated a bit of discussion time here <infinity> slangasek: FWIW (and this may influence your vote), the empty stubs contain instructions on how to install it from both upstream's builds and juju charms. * pitti is running the owncloud debs from upstream, they work reasonably well and get updated <slangasek> infinity: and is there a debconf notice at install time? <infinity> slangasek: But feel free to vote FD. ;) <pitti> not in the current upload <kees> can we document the "empty upload" policy so we can reuse it when we hit these things again? <pitti> FWIW, I was voting about the general "replace them with empty stub", not the precise implementation; debconf seems fine to me, too <infinity> slangasek: I'd think a double-whammy of NEWS.Debian and a debconf note might help. <slangasek> I do think this is the right principle <slangasek> but it's important that the user who upgrades knows what's what <infinity> Happy to have someone document one of both of those as a requirement in the bug to go with our decision. <slangasek> so on that basis, +1 <slangasek> +1 <meetingology> +1 received from slangasek <infinity> s/one of/one or/ <infinity> [ENDVOTE] <meetingology> Voting ended on: replace owncloud packages with empty stubs, since no one's willing to maintain it <meetingology> Votes for:6 Votes against:0 Abstentions:0 <meetingology> Motion carried <AnybodyElse> (Thanks - upstream guy here. We had A LOT of users that installed the outdated Universe package.) <infinity> slangasek: Want to follow up to https://bugs.launchpad.net/ubuntu/+source/owncloud/+bug/1384355 with the "please add a debconf note" mention? <mdeslaur> kees: the policy on the technical way to do it, or on when it's appropriate to do <slangasek> will do <infinity> mdeslaur: The former, I'd think. <infinity> mdeslaur: "Appropriate" is always a case-by-case thing. <kees> mdeslaur: I meant the former, but probably we need both. <kees> and for the latter, yeah, say "case-by-case" but give past examples since it's so rare (Java, e.g.) <mdeslaur> AnybodyElse: hi! <infinity> mdeslaur: "Upstream asked" isn't a good enough reason (LOTS of upstreams don't want us shipping their stuff), but "upstream asked, and it's actively harmful to users because we have no distro maintainers looking at it" is probably sane, etc. * AnybodyElse waves back to mdeslaur :) <slangasek> I don't think "no distro maintainers" is sufficient cause to say that it's actively harmful to users <pitti> it's even more of a no-brainer in precise where universe isn't supported any more, but for trusty it's an actual problem indeed <infinity> slangasek: Right, "no distro maintainers, and it's woefully out of date with security issues" blah blah. <slangasek> yes <infinity> slangasek: Hence my "case-by-case" statement. <slangasek> if we were going to leave this to be case-by-case, there's no reason to involve the TB <slangasek> a policy should be an actual policy :) <infinity> Fair point. <slangasek> anyway, commented on the bug <infinity> It's a hard policy to nail down precisely. The best we can do is provide guidance, I think, so SRU people have something to point at as a reference. <slangasek> is someone taking the action to draft a policy? <pitti> that should go on https://wiki.ubuntu.com/StableReleaseUpdates, right? <slangasek> yes, I would say so <infinity> pitti: Ultimately, I'd think it would be there, or linked from there. <pitti> or a subpage; at least under that domain <infinity> https://wiki.ubuntu.com/StableReleaseUpdates/Removals perhaps. <pitti> yeah, and linking from /SRU; although it wouldn't be very long, maybe two paragraphs <infinity> kees: Since you brought it up, feel like drafting a (non-pretty, rambling text and bullet points is fine) first cut of a sane-seeming policy for considering removal requests, and we can argue about it in two weeks? <pitti> ^ or on the list <slangasek> "maybe two paragraphs" to me says it shouldn't be a subpage, but ymmv and doesn't need bikeshedding <infinity> pitti: Well, it could be a removal policy in general, so could grow. So, security issues, like owncloud, IP takedown issues, etc. <pitti> I was in the middle of typing "I can try and draft something", but if kees wants to do it, I'm all for it :) <infinity> pitti: Well, if you're volunteering, I doubt kees will assert ownership of the idea. :P <pitti> oh, it should just be the "how", and maybe some guidelines of "when", but I'd keep it as a case-by-case decision <pitti> such things are hard to pinpoint in a policy <infinity> [ACTION] pitti to draft initial removal-as-an-SRU policy document with a less lousy name than the one used in this action. <meetingology> ACTION: pitti to draft initial removal-as-an-SRU policy document with a less lousy name than the one used in this action. <mdeslaur> does the SRU team remain authoritative on empty package SRUs? <infinity> mdeslaur: The SRU team remains generally authoritative over the -proposed queues in general, I think, though we lack a constitution for me to base that statement on. :P <mdeslaur> infinity: ok, that's fine with me <infinity> mdeslaur: As far as I read our non-constitution, we can override any of the delegate technical teams (like AA, SRU, etc), but overriding isn't the same as making all their decisions for them. * mdeslaur nods <infinity> Anyhow. Skipping along. Going to bounce the CFQ thing until Riddell pops up. <pitti> well, the SRU team is bound by the policy in https://wiki.ubuntu.com/StableReleaseUpdates <infinity> pitti: They write the policy, so "bound" is a curious term. <pitti> infinity: I think it was actually written by the TB <pitti> and all changes certainly were approved by the TB <infinity> pitti: Well, I've certainly amended it a lot when I wasn't on the TB. :P <infinity> Anyhow, a governance discussion seems like it would take the whole meeting slot, and we have a busy week for once. <pitti> CFQ> not sure if there's much else to discuss; it's rock <-> that SRU <-> hard place <infinity> [TOPIC] Dismantling the ARB <infinity> stgraber: Care to wax poetical on this topic? <pitti> the main question I'd have is whether this can be done less intrusively with the blkio cgroup controller, but I think that was already handled in the ML <stgraber> sure <stgraber> so the ARB hasn't done anything since precise, all members expired and all we've done so far is create the extras.u.c entry every time we open a new release <stgraber> I believe it's now time to just kill it entirely and remove the repository in 15.04 * kees sharpens the axe <pitti> oh, so it's practically non-existing already anyway? <infinity> pitti: Right, it's dead, it just needs to be told it's dead. <stgraber> correct, no packages published since precise and I'm the only member of the ARB team on LP (and only there because I'm doing the series initialization every 6 months) <pitti> kees: axe? I thought a wooden spile through the heart is better for zombies? <kees> hehe <infinity> So, we need a technical solution to the removal of extras from users' systems on upgrade, and to take a TB decision to un-delegate the team and whack it from LP? <kees> I think spikes are for vampires <mdeslaur> stgraber: perhaps I'm confused, but isn't there activity in the weekly reports? <stgraber> nope <stgraber> you're confusing this with the commercial app stuff I suspect <mdeslaur> oh, yes, I am <mdeslaur> I keep confusing those two <mdeslaur> sorry, please ignore me <infinity> slangasek: As the engineering manager who happens to own the technical side of this discussion (ubuntu-release-upgrader, probably?), are you happy with mandating the removal of extras and making that happen? <infinity> (Note that it doesn't need to be done in concert with killing the team, we just really should stop shipping a useless empty repo line in sources.list) <infinity> Well, release-upgrader for upgrades, and installers for new installs. <slangasek> infinity: I think it's clear that this is what needs to be done, yes <slangasek> infinity: just make sure this decision turns into a bug report :) <infinity> Right, do we need a formal vote on the undelegation of the team? <stgraber> yeah <infinity> [VOTE] undelegate the ARB and remove the team from LP <meetingology> Please vote on: undelegate the ARB and remove the team from LP <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) <infinity> +11 <meetingology> +11 received from infinity <stgraber> +1 <meetingology> +1 received from stgraber <mdeslaur> +1 <meetingology> +1 received from mdeslaur <slangasek> +1 <meetingology> +1 received from slangasek <pitti> +1 <meetingology> +1 received from pitti <slangasek> +1!! <meetingology> +1!! received from slangasek <kees> +1 <meetingology> +1 received from kees <infinity> [ENDVOTE] <meetingology> Voting ended on: undelegate the ARB and remove the team from LP <meetingology> Votes for:6 Votes against:0 Abstentions:0 <meetingology> Motion carried * slangasek one-ups infinity <pitti> infinity has chair has 11 times the voting power?? <slangasek> because 1-factorial-factorial is better than 11 <infinity> pitti: According to the bot, no. <infinity> stgraber: Can you file a bug report on whatever components you can think this affects? <infinity> stgraber: u-r-u, apt-setup, ubiquity, livecd-rootfs, maybe curtin... <pitti> infinity: (j/k) <infinity> pitti: I was curious to see if it would tally it oddly, but I guess it's smarter (or, realistically, dumber) than that. <stgraber> infinity: sure. I'll also take care of killing off the team and any documentation I can find <infinity> stgraber: \o/ <pitti> rest in peace, extras.u.c., and be replaced click apps.. <mdeslaur> stgraber: aim for the head <infinity> [TOPIC] Community bugs: 0 <pitti> "with" <infinity> Subtopic there... The community bugs review is almost always 0. Is this a sign that people aren't escalating things they should, or that Ubuntu is so super healthy that there's no need? <infinity> Should we be advertising a more friendly "hey, you can assign bugs to us when they need guidance" stance? <slangasek> is Riddell's SRU escalation not a "community bug"? <infinity> Oh, true, it's just not in the search link. :P <slangasek> I guess technically there wasn't a bug report assigned to us, sure <slangasek> but I don't think we care about the escalation vector, really <pitti> I can remember only one community bug ever.. <infinity> Alright, maybe it's working as designed, then. <infinity> [TOPIC] Mailing list review <infinity> Which I think probably brings us full circle to CFQ. * slangasek nods <infinity> Does anyone have any new opinions on that that they haven't voiced on the list? <pitti> nothing new, really; if Kubuntu wants to go ahead with that, I see relatively few other options, as AFAIR the "low blkio priority in cgroup" idea was already discarded? <pitti> but slangasek's test plan looked fairly comprehensive <infinity> I'm personally in the "It's probably harmless (will change performance one way or another in a lot of scenarios, but I trust the upstream code to not be BROKEN)" camp, but I'm still concerned with a userspace package for desktop_foo changing the behaviour for a multi-desktop system. <infinity> But maybe that fear is silly, as multi-DE installs are hugely uncommon, and reserved for the nerdy. <slangasek> I don't think there are any blockers here, except for "SRU team has time for review" and "someone involved in this SRU acknowledges the testing requirements and updates the SRU bug accordingly" <slangasek> currently the SRU test case shown is the original one, which is incomplete <infinity> Riddell: Since you seem to still be idle, when you get back and read backscroll, can you address Steve's bug paperwork concerns? <slangasek> infinity: it's not just multi-desktop systems; as xnox pointed out on ubuntu-release@, it will impact the system performance characteristics for users running, e.g., a VM on top of a kubuntu desktop <infinity> Riddell: Thanks in advance. :P <infinity> slangasek: Sure, but I'm not sure layering like that is a thought exercise worth getting into. <slangasek> not sure what you mean <infinity> slangasek: Ubuntu in a VM performs differently if the host is Ubuntu or RHEL too. Oh well. <slangasek> I'm not talking about layering <slangasek> I'm talking about "if you run a VM on kubuntu you will be in pain" <slangasek> as in, your desktop experience will regress <mdeslaur> no, heavy disk io, whether created by a VM that's running, or simply copying files off of a USB disk <infinity> slangasek: I think "you will be in pain" is an exaggeration, but this is where some good testing is a solid plan. <slangasek> maybe I have a low pain tolerance ;) <slangasek> anyway, actionability here - next step is for the Kubuntu devs to lay out their explicit test plan in the SRU bug? <infinity> slangasek: But okay, I see what you mean here. My take was "kubuntu can do what they want to kubuntu as long as it's not actively harmful". <infinity> In a broad sense. Obviously not in any willy nilly SRU, hence the discussion. <slangasek> well, I think the SRU team has a duty to protect Kubuntu users from regressions too <infinity> slangasek: Anyhow, on the off chance that Riddell's missed backscroll, can you poke the list thread with a re-request for better paperwork? <slangasek> infinity: can you just [ACTION] it and send out minutes? :-) <infinity> Maaaybe. <slangasek> I mean [ACTION] Riddell, not me <infinity> [ACTION] Riddell to improve the CFQ SRU paperwork to detail regression testing plans <meetingology> ACTION: Riddell to improve the CFQ SRU paperwork to detail regression testing plans <infinity> [TOPIC] Next chair <infinity> Should be kees, unless he's got other plans. <infinity> kees: ^ <infinity> Hrm, next meeting would be Nov 11. A lot of countries take that off. <kees> yup <kees> oh? <infinity> Should we defer for a week, or jiggle it around? <slangasek> "a lot of countries"? <kees> oh, so it is. <infinity> slangasek: Well, some. I'm not sure who. :P <slangasek> oh, right <kees> "a lot of the board are in country that takes it off" <slangasek> we didn't actually invent that date, we just rebranded it ;-) <kees> I vote to skip it. <pitti> there's still the ML <pitti> for discussing CFQ etc. <kees> I can run the 25th meeting, then? <infinity> [VOTE] Skip Nov 11 meeting, so people can buy poppies and be appropriately respectful <meetingology> Please vote on: Skip Nov 11 meeting, so people can buy poppies and be appropriately respectful <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) <infinity> +1 <meetingology> +1 received from infinity <kees> +1 <meetingology> +1 received from kees <mdeslaur> +1 <meetingology> +1 received from mdeslaur <stgraber> +1 <meetingology> +1 received from stgraber <slangasek> +1 <meetingology> +1 received from slangasek <infinity> Right, the 1s have it. <infinity> [ENDVOTE] <meetingology> Voting ended on: Skip Nov 11 meeting, so people can buy poppies and be appropriately respectful <meetingology> Votes for:5 Votes against:0 Abstentions:0 <meetingology> Motion carried <infinity> kees: You've got the 25th, then. <slangasek> (poppies? I thought this day was for celebrating heroes, not heroin) <infinity> slangasek: Canadians celebrate by getting high. <infinity> [TOPIC] AOB <slangasek> that seems like a truism <infinity> Anything else? <pitti> nothing from me <slangasek> not here <infinity> slangasek: It's symbolic of the poppies that grow among the graves in Flanders Fields. <slangasek> huh <slangasek> learn something new * mdeslaur learns something new <infinity> #endmeeting <meetingology> Meeting ended Tue Oct 28 17:49:36 2014 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2014/ubuntu-meeting-2.+1-226-633-4109.01.moin.txt <kees> thanks! <slangasek> thanks! <mdeslaur> thanks everyone! <stgraber> thanks! <pitti> thanks everyone #ubuntu-meeting-2 2015-10-06 * dsmythies realizes he forgot the pleia2 "Meetingology bit crash course" notes. Just a minute... * dsmythies ... Oh, found them ... <tedmcox> who updates the links at the top of the webchat window? the fridge and meeting logs links are outdated <dsmythies> #startmeeting Ubuntu Docs <meetingology> Meeting started Tue Oct 6 16:59:55 2015 UTC. The chair is dsmythies. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <dsmythies> #chair dsmythies GunnarHj <meetingology> Current chairs: GunnarHj dsmythies <GunnarHj> Hi all! <dsmythies> Tead asked (repeating just to log it): who updates the links at the top of the webchat window? the fridge and meeting logs links are outdated <dsmythies> Teadmcox, there is no specific person assigned to that task. Someimtes I do it, sometimes Peter Matulis... <dsmythies> Who is here for the doc team meeting? so far I have Gunnar, Ted, myself <tedmcox> this appears to be the current fridge/calendar link: http://fridge.ubuntu.com/calendars/ <GunnarHj> Small meeting. <dsmythies> tedmcox, sorry I misunderstood. The banner when you join this room is maintained by, I think, pleia2 <tedmcox> OK, I'll ping pleia2 <GunnarHj> Hi pmatulis! <tedmcox> Oh, and hello, everyone :) <pmatulis> hi GunnarHj and dsmythies and tedmcox <dsmythies> GunnarHj: pmatulis is on the road. However he did mention he might be here in the background. <dsmythies> Oh, missed that <dsmythies> moving onto the agenda... <dsmythies> quiet cycle for docs for 15.10. Not much to say really. <dsmythies> tedmcox thanks for your work on serverguide while at the openhelp conference. <tedmcox> dsmythies, thank you for your help during the sprints! <tedmcox> hi, shaunm! <dsmythies> tedmcox: did you notice that it seems to be the much older serverguide bug reports that we don't seem to get to? They are the harder ones, that need subject matter experts to help with. <tedmcox> yes, i noticed that <shaunm_> hi tedmcox <dsmythies> Anything esle before we move onto help.ubuntu.com? <tedmcox> some older items may also need to be marked as wishlist, but i don't have the ability to do that <dsmythies> GunnarHj: Thanks for splitting out launchpad help.ubuntu.com into its own project, It was very annoying before. <GunnarHj> Yeah, and it allows us to have a separate bug tracker for those issues. <dsmythies> tedmcox: Probably a good idea. <dsmythies> There was a way before to have bugs specific to help.ubuntu.com, but it was very strange and I could never remember how. <dsmythies> which is why I tended to have under ubuntu-docs <GunnarHj> I have nothing more to say about help.ubuntu.com. <dsmythies> By the way, I'll probaly start soon on the preliminary adding of 15.10 to help.ubuntu.com, but only on my test linda89@example.com. <GunnarHj> dsmythies: Excellent. But wait until I have updated the translations (probably Friday). <dsmythies> I'll hope to keep an open, but unsubmitted bzr branch during that time. <dsmythies> GunnarHj: O.K. will wait until after translations update. <dsmythies> moving on... <dsmythies> Misc: 3 are just statements, really. Fourth is time / day for meeting, which I suggest we handle on the e-mail list. We will have a conlfict next month again. <dsmythies> Oh, any followup for ted from his openhelp e-mail <dsmythies> svetlana isn't here, for her take on things. <GunnarHj> tedmcox: Thanks for your list email about the conference! <dsmythies> yes, thanks ted. <tedmcox> there are a few ideas i will probably post on the list in the next couple of weeks <dsmythies> And thanks shuanm_ for putting the whole thing together <tedmcox> creating a to-do list of some kind for contributors <GunnarHj> +1 <dsmythies> tedmcox: O.K. great. <GunnarHj> tedmcox: Sounds awesome. <tedmcox> setting up some kind of feedback box on our html pages for easier feedback from readers <tedmcox> the big one: how feasible is it to use a lightweight doc tool (markdown, asciidoc, etc) for our docs? <GunnarHj> There is one idea, which pmatulis brought up a while ago, I'd like to add: We should explicitly offer mentors to persons who want to get started. <tedmcox> that last one would take considerable effort <GunnarHj> tedmcox: I thought that Mallard was a lightweight markup language. And now I hear something about lightweight Mallard... <tedmcox> +1 for mentors <dsmythies> tedmcox: We do seem to often talk about changing the markdown language. It would be a massive project, and I tend to think underestimated. <tedmcox> gunnarHj: yes, ducktype . that's shaunm's project. <GunnarHj> shaunm_: Are you planning to switch to that for the GNOME docs? <tedmcox> switching from Docbook to something lighter would be a huge undertaking. i don't know if making that effort would pay off with more community contributions. <GunnarHj> tedmcox: I do agree on the doubt. <dsmythies> tedmcox: I also agree on the doubt. <shaunm_> GunnarHj: I don't know if gnome will switch to ducktype <tedmcox> i'll look around. there may be some tool out there that helps automate that conversion process. <dsmythies> I am going to copy something from #ubuntu-doc to here, since Ted isn't in that room: <GunnarHj> shaunm_: Ok. <dsmythies> anyone with an ubuntu member cloak can change the topics in meeting channels, but lmk what's wrong and I can help fix things post-meeting as needed (that was from pleia2) <dsmythies> tedmcox: it sin't the conversion process that is the show stopper. It is the translations workflow that is typically the show stopper. <shaunm_> GunnarHj: I view both mallard xml and ducktype as viable, with different strengths and weaknesses. I don't think everybody will choose to go lightweight. <GunnarHj> shaunm_: I see. Personally I like Mallard. Reasonably simple, and preventing you from overcomplicating things. <dsmythies> tedmcox: For your thread "Committing multiple branches to Launchpad": Does the feedback all make sense now? <GunnarHj> dsmythies: But the translations workflow doesn't affect all contributors, does it? It's typically handled by one or two persons. <tedmcox> dsmythies: yes, i'll commit multiple smaller changes to one branch from here on <dsmythies> GunnarHj: Yes, but the entire workflow has to be considered, and estimated, when considering fundamental changes. That is where I felt we fell short in past conversations. <GunnarHj> dsmythies: We can talk more about it past meeting, if you like. <pmatulis> tedmcox: i've already gone through a test process of converting from docbook to RST markdown. it works but resulted in a lot of broken hyperlinks <shaunm_> basically, for any format you're considering, you need to make sure there are good tools to round-trip with po files <shaunm_> because po files are how translators get work done <shaunm_> ideally, there'd be a way to communicate extra information about the document that's useful to translators <GunnarHj> shaunm_: Indeed. Realizing now that that's what dsmythies was talking about. <pmatulis> tedmcox: ahoneycutt (spelling?) is also interested in this project <dsmythies> shaunm_, yes agreed. <dsmythies> I did hear from ahoneycutt (spelling?) that he couldn't get away from work to attend this meeting. <tedmcox> cool. i'll talk to aaron. <dsmythies> Hannie also said she was unable to attend. <GunnarHj> ahoneybun (correct spelling!) seems to be connected to this room. <tedmcox> any chance any of you know of other projects that made a big switch similar to what we're discussing? i can reach out for their feedback. <dsmythies> I do not know of other projects. <GunnarHj> tedmcox: A few years ago the desktop guide switched from DocBook to Mallard. But it was because GNOME used Mallard, and not to make it easier to contribute. I think the difference in the latter respect is minimal. <dsmythies> Are there any action items? tedmcox to do some followup e-mails with some ideas from the openhelp conference, for example. <GunnarHj> dsmythies: That would be a suitable action item IMO. Then we can keep talking on the list. <tedmcox> that sounds good <dsmythies> #action dsmythies to start (yet another) team meeting date / time change e-mail thread. <meetingology> ACTION: dsmythies to start (yet another) team meeting date / time change e-mail thread. <dsmythies> #action tedmcox to do some followup e-mails with some ideas from the openhelp conference <meetingology> ACTION: tedmcox to do some followup e-mails with some ideas from the openhelp conference <dsmythies> Anything else? <dsmythies> tedmcox: Will you follow up with your banner issues with pleia2? <tedmcox> yes <dsmythies> I think we are done. <GunnarHj> Thanks everyone! <dsmythies> I'll wait one minute, then terminate <dsmythies> Yes, thanks everyone. <dsmythies> #endmeeting <meetingology> Meeting ended Tue Oct 6 17:51:31 2015 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.+1-226-633-4109.59.moin.txt #ubuntu-meeting-2 2015-10-13 <infinity> o/ * infinity listens to the crickets. <pitti> o/ <kees> \o <pitti> welcome to another episode of "meeting with no agenda" :) <infinity> slangasek: *stab* <kees> \o/ (I will raise the other arm now) <infinity> So, we seem to be Steveless, and Stephane and Marc sent apologies. <infinity> #startmeeting <meetingology> Meeting started Tue Oct 13 16:03:02 2015 UTC. The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <infinity> As pitti pointed out, we're pretty much agendaless. <pitti> Steveless too? <infinity> [ACTION] pitti to update SRU policy wiki page and announce on u-d-a <meetingology> ACTION: pitti to update SRU policy wiki page and announce on u-d-a <pitti> done <infinity> pitti: ^-- That's all done? <infinity> Yay. <infinity> Looks like Steve didn't cover his action, so we'll carry that. <infinity> [TOPIC] List archives <infinity> No posts in the last month. So, that's kinda special. <infinity> Anyone have any off-list mail threads they want to bring up? :P <pitti> nothing from me <kees> nope <infinity> Exciting meeting, this one. <infinity> [TOPIC] Community bugs <infinity> 0 <infinity> Nada. <infinity> Nil. <infinity> Zip. <infinity> Zilch. * kees shakes hands all around, "well done, everyone" <infinity> [TOPIC] Next chair. <kees> me I think? <infinity> Looks like it should be stgraber (who I was filling in for), and then kees. <kees> oh <kees> gotcha <infinity> Will update the wiki accordingly. <infinity> [TOPIC] AOB <infinity> Anyone have any OB? <infinity> Not to be confused with BO. <infinity> Or B0, for the ASM nuts. <infinity> Going once. <infinity> Twice. <infinity> #endmeeting <meetingology> Meeting ended Tue Oct 13 16:09:06 2015 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.+1-226-633-4109.03.moin.txt <pitti> thanks kees and infinity :) <kees> thanks infinity and pitti :) <infinity> wiki updated. #ubuntu-meeting-2 2015-10-27 * mdeslaur looks around <mdeslaur> hrm <mdeslaur> hi stgraber <stgraber> hey <stgraber> lets see who's around <stgraber> we have no pitti, no kees and maybe no slangasek <mdeslaur> yeah <mdeslaur> are you travelling? <stgraber> I vaguely remember seeing an e-mail about infinity being off this week or something <stgraber> no, I'm home for once :) <mdeslaur> nonsense, infinity is never off :P <stgraber> :) <mdeslaur> tbh, it's been awfully quiet, so you may be right :) <stgraber> pinged him anyway <stgraber> will start in a few minutes, not that we really have anything to discuss at all or even have quorum for that matter :) <mdeslaur> yeah, if it's just us, we can probably cancel <slangasek> infinity may have been encouraged to use some of his vacation <mdeslaur> hehehe <slangasek> so I'm here but multitasking <stgraber> #startmeeting Technical Board meeting <meetingology> Meeting started Tue Oct 27 17:10:08 2015 UTC. The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <stgraber> #topic Apologies <stgraber> Received apologies from pitti, kees and slangasek (though he's still around but multi-tasking). <stgraber> #topic Action review <stgraber> ACTION: slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases <stgraber> slangasek: did you have time to look at this or should we keep it around? <slangasek> stgraber: it's still on my carryover list <stgraber> alright <stgraber> sorry, multi-tasking too :( <stgraber> #topic Scan the mailing list archive for anything we missed (standing item) <stgraber> we don't have any scheduled agenda item today, lets see if there's something we should discuss from the list <stgraber> only thing I see are apologies so guess not :) <stgraber> #topic Check up on community bugs (standing item) <stgraber> nothing there <stgraber> #topic Anything else? <stgraber> does anyone have something we should discuss? <slangasek> nothing here <mdeslaur> nope <stgraber> #topic Select chair <stgraber> so according to the wiki, that should be infinity <stgraber> unless he ended up chairing when I wasn't around? <slangasek> I think he did actually <slangasek> (which is why Kees was listed as next: for today) <slangasek> stgraber: so, kees as next chair? <slangasek> (did I fall off the Internet or is it really quiet in here :) <stgraber> just really quiet <stgraber> ok, so kees is next <stgraber> #endmeeting <meetingology> Meeting ended Tue Oct 27 17:22:09 2015 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.+1-226-633-4109.10.moin.txt <stgraber> thanks everyone for attending this very short meeting :) <mdeslaur> thanks stgraber, slangasek <slangasek> thanks <stgraber> agenda updated #ubuntu-meeting-2 2016-10-11 <kees> o/ <mdeslaur> hi! * slangasek waves <slangasek> kees: probably assume infinity is not chairing two days before release <kees> ohhhh hm. <kees> loading stuff... <kees> #start-meeting <kees> #startmeeting <meetingology> Meeting started Tue Oct 11 16:01:50 2016 UTC. The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <kees> #topic action review <kees> ACTION: infinity to follow up with maas SRU exception <kees> anyone know status of this? * mdeslaur doesn't know <kees> deferred! <kees> ACTION: infinity to play with seed/maint-check changes on dogfood to build a new xenial release pocket for support length auditing <kees> this one? <mdeslaur> I think that needs deferring also <kees> deferred! <kees> ACTION: mdeslaur to look into flavour CVE tracking <mdeslaur> please defer, I'll look at that next week <kees> deferred! <kees> nothing else to do. :P <kees> #aob <kees> mdeslaur i think you're next to chair after me? <mdeslaur> ok <kees> cool. shortest meeting evar <stgraber> :) <kees> #endmeeting <meetingology> Meeting ended Tue Oct 11 16:08:12 2016 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.+1-226-633-4109.01.moin.txt <kees> thanks everyone! :) <mdeslaur> thanks! :) <slangasek> kees: I think you actually have some competition in the history for 'shortest meeting', but thanks :) <kees> i do, yeah. those deferments slowed me down ;) #ubuntu-meeting-2 2016-10-25 <mdeslaur> \o <infinity> o/ <slangasek> o^ <infinity> stgraber? <infinity> And I see no kees. <infinity> #startmeeting Technical Board Meeting <meetingology> Meeting started Tue Oct 25 16:00:40 2016 UTC. The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <infinity> Hai. <slangasek> hello <infinity> #topic Action Review <infinity> The MaaS thing is deferred yet again, I really need to jump on that. <infinity> And I'm setting an ETA of 16.04.2 release for the xenial support header fixups. <infinity> mdeslaur: flavour CVE stuff? <mdeslaur> my item is deferred again also....I swear I'll work on it soon, just as soon as the CVEs stop coming in :P <infinity> Right, I'll ask people to stop finding bugs. <infinity> Should work. <mdeslaur> cool <infinity> #topic mailing list review <infinity> I see nothing since September. <infinity> #topic Community Bugs <infinity> Nein. <infinity> #topic Next chair <infinity> Based on the last meeting's log, looks like it's mdeslaur up next, with a backup of slangasek. <slangasek> sounds about right <mdeslaur> sounds good <infinity> #topic AOB <infinity> So, who has fun OB? <mdeslaur> I don't <infinity> *crickets* <infinity> So, next meeting is scheduled for US election day. Will the Americans be able to vote and still make the meeting? <infinity> And, indeed, will any of us be able to get anything done while glued to our TVs for 12 hours with Trump anxiety? <slangasek> the Americans on this team all vote by mail <infinity> Good for you. Then we'll keep it on the schedule. <slangasek> (as in, that's the only way to vote in this state :) <infinity> If nothing else, then... <infinity> #endmeeting <meetingology> Meeting ended Tue Oct 25 16:07:31 2016 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.+1-226-633-4109.00.moin.txt <slangasek> infinity: thanks :) <mdeslaur> thanks infinity! <infinity> Wiki updated. #ubuntu-meeting-2 2017-10-10 <mdeslaur> \o <slangasek> mdeslaur: hi <mdeslaur> hi slangasek <slangasek> mdeslaur: at sprint so only sorta here, sorry * stgraber waves <stgraber> same as Steve <mdeslaur> hi stgraber <mdeslaur> ok, kees isn't here <mdeslaur> looks like there's nothing to discuss on the mailing list, and no open bugs <mdeslaur> let's skip this meeting once again <stgraber> :) #ubuntu-meeting-2 2017-10-24 <mdeslaur> hi <mdeslaur> hrm <mdeslaur> anyone here today? <slangasek> oops <slangasek> mdeslaur: hi, sorry, no highlights == not looking in the right window :) <slangasek> I realized I was late as I was processing the DMB's PPU acl request <mdeslaur> no infinity, no kees <mdeslaur> stgraber: are you here? <mdeslaur> ok, nothing new on the mailing list, nothing new in the bug tracker, everyone is missing. <mdeslaur> meeting cancelled. <mdeslaur> slangasek: ^ <slangasek> :/ #ubuntu-meeting-2 2019-10-01 <xnox> !tech-board <xnox> !tech-board-ping #ubuntu-meeting-2 2019-10-08 <mdeslaur> \o <xnox> o/ <mdeslaur> lefty * vorlon waves <xnox> ~ <infinity> o/ <infinity> Sorry I'm late. <mdeslaur> hi infinity <vorlon> wiki claims that chair and backup chair are both awol <infinity> I guess that wraps around to me again, then. <infinity> [startmeeting] Ubuntu Technical Board <infinity> Wait, have I lost my mind? * xnox O_o <mdeslaur> [topic] has infinity lost his mind? <vorlon> do you mean #startmeeting? <infinity> Yeah. I do. <infinity> #startmeeting Ubuntu Technical Board <meetingology> Meeting started Tue Oct 8 19:06:52 2019 UTC. The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <infinity> I haven't meetbotted in a while. <infinity> So, who's here? vorlon, mdeslaur, infinity? Izzat it? <infinity> Looks like. <mdeslaur> yep <xnox> no kees? <infinity> #topic Action review! <infinity> ACTION: vorlon to follow up w/ DMB on request to require 6-month expiry policy for flavor developer teams <vorlon> last thing I was told is that there hasn't been a DMB meeting since my request, due to lack of quorum <mdeslaur> :( <infinity> Shiny. I think we have something on the agenda to deal with that later. :P <infinity> ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. <vorlon> I haven't seen anything on this yet <infinity> Ditto. <vorlon> but this can be Wimpress's regular fortnightly irc highlight nag <infinity> ACTION: infinity to ask maas team to prepare SRU exception policy Ã la CurtinUpdates (see https://wiki.ubuntu.com/MAASUpdates) (awaiting response from rbasak) <infinity> I meant to get together with my nemesis and discuss their plans for MAAS going forward (ie: are they killing the deb). I'll do that. <infinity> ACTION: vorlon 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. <vorlon> mm carry-over <infinity> ACTION: vorlon to reply to seeded snap upload permissions question on list <vorlon> and my other two also :/ <infinity> Right, I won't paste the next one, then. :P <infinity> #topic New and shiny things <infinity> [cyphermox] Reinstate / extend membership of cyphermox and jbicha in DMB for elections <infinity> It seems we entirely ignored cyphermox's email about this? * Wimpress hangs head in shame <vorlon> seems so <vorlon> shall I go push the button right now, while you carry on with the meeting agenda? <infinity> I can JFDI this request, if there are no objections? <infinity> Or you can. <mdeslaur> infinity: +1 <infinity> +1 from me too. <infinity> Go for it, Steve. <mdeslaur> heh <infinity> [xnox] Please review proposal for OEM archive integration into Ubuntu Project mailing list post <infinity> https://lists.ubuntu.com/archives/technical-board/2019-August/002456.html <vorlon> done with a 3-month extension <xnox> I am looking for guidance, if we Ubuntu Project wants to provide an opt-in upgrade path from Vanilla to Canonical-OEM-collaborated archives, or not. And if yes, how to do it. <infinity> xnox: Are you proxying a request from a Canonical engineering team on this, or was this just you trying to make things better? <xnox> The proposal, is to ship just enough shims in the Ubuntu Archive, that will offer users to ugprade to "Ubuntu Certified" <vorlon> I had asked xnox to refer this to the TB, based on the nature of the request to add additional archives to an Ubuntu install and our precedent that such things should have TB oversight <infinity> Except that the point of the OEM stuff is to move people as quickly as possible to generic stuff, not the other way around. <xnox> infinity: proxying request from Lenovo, stgraber (i bought certified machine, why nothings works), and the OEM team. <xnox> infinity: separate instances of the same thing, as to why "ubuntu.com/download" never leads to "certified experience" <vorlon> infinity: right, the issue is that you buy a certified machine but do a stock Ubuntu install and don't get the certified experience <mdeslaur> I see why this would be beneficial to users <infinity> Discounting the external archive issue, I'd be concerned that if "the OEM archive" and "the OEM kernel" become the new hotness that everyone "upgrades" to, we're moving users in exactly the opposite direction form what we want. <mdeslaur> as long as the incentive to get stuff into the archive doesn't go away <mdeslaur> who has upload rights to those ppas? <xnox> many machines get certified with a delay, of 3 months+, such that one might have "all of their hardware bugs fixed" if we push out a meta-package with metadata to pull in linux-oem kernel and other device specific fixes which haven't yet made their way to GA kernel, etc. <xnox> mdeslaur: canonical OEM controls the signing keys, whilst the software is opensource and created in collaboration by Canonical OEM, Canonical Kernel, Vendor, & Vendor suppliars teams. <vorlon> infinity: upstreaming the per-device or per-OEM specific fixes into the Ubuntu archive takes non-zero time, and while we want to drive the set of oem customizations to zero post-certification, there should never be a point in time that a machine is certified but they can't make the hardware work with Ubuntu <infinity> I'm also somewhat curious, on a technical level, how you intend to devise modaliases narrow enough to target the machines we want and not get, say, every thinkpad in the last three years. <xnox> there might be non-open source suff, like documentation / manuals / guides from the Vendor. <infinity> vorlon: Yeah, I understand the problem this is attempting to solve. <xnox> infinity: OEM teams have specific modaliases of specific revisions of specific hardware that is paid for to be certified. and those modaliases will be advertised. <mdeslaur> xnox: that doesn't really answer my question...who has upload rights to the ppa? <infinity> I just want to be sure it's not creating larger problems (like disincentivising moving things out of OEM silos) <vorlon> infinity: ack <vorlon> I think that's something we need to pay attention to, but I don't see how anything /other/ than a set of OEM archives can solve the root problem <xnox> infinity: by nature, those things spike at a product release / certification time, and then continiously make their way into generic kernel & vanilla packages, thus eventually the delta decreases. <infinity> Also, these PPAs have no community oversight. linux-oem is something we can exert some control over, random junk hacked up in a PPA is another story. <xnox> infinity: unless there is OEM hotfix for firmware / restrict wifi & bluetooth regulatory RF bands / etc. <vorlon> prior art here included the ubuntukylin commercial archive; I don't recall there being community oversight for that? <xnox> mdeslaur: upload rights, i believe it is Canonical OEM team, and that excludes linux kernel, as the linux-oem* kernel flavours are in teh Ubuntu Archive proper - just currently never installed automatically / nor like offered to be opted linda89@example.com. <vorlon> [LINK] https://lists.ubuntu.com/archives/technical-board/2014-April/001867.html <infinity> Indeed not. And there was much handwaving over allowing that. <vorlon> (^^ reference) <xnox> mdeslaur: infinity: the archives are on the public internet right. So anybody has access to them, including sources. <xnox> mdeslaur: infinity: and that's why i want the OEM archive key be shipped by a package in the Ubuntu Archive, such that if we don't feel comfortable, we can push out an update that removes the key & those archive repositories too from the Ubuntu Project. <mdeslaur> will this new archive be opt-in in the software properties gui? <vorlon> from my POV it's a requirement that it be opt-in, not opt-out <infinity> Very much so. <xnox> mdeslaur: i was more thinking ubuntu-drivers pages of software properties gui, but yeah somthing like popup "new software is available to support your Lenovo" <xnox> mdeslaur: which one can choose to opt-into, or ignore. <mdeslaur> xnox: all vendors will be in the same archive? <infinity> What sorts of things live in this PPA? Do they fork Ubuntu packages? <xnox> mdeslaur: at the moment there is a different archive per-vendor, because they don't like to see each others / unrelated things. <infinity> Cause downgrading from a PPA removal is gross. <xnox> mdeslaur: the contents is the same / harmonised across them. and all of them are signed by the same key as far as I was able to trace them. <infinity> xnox: Are all the packages in these archive unique, or are some of them forks of things in the primary archive? <xnox> infinity: majority of it, is opt-into specific Xorg stack and opt-into specific linux-oem flavour and ship docs. <infinity> "specific xorg stack" sounds like forks... <infinity> Unless it's uniquely-named driver packages built to work with the xorg in the archive. <xnox> infinity: no, as in use the -hwe xorg stack from the Ubuntu Archive <xnox> instead of the ga hwe stack <xnox> (meta package dependencies) <xnox> (and conflicts) <infinity> Okay, none of that requires an external archive. <infinity> So, what's in the external archive that we want? <xnox> infinity: they do fork some things, there was fwupd hotfix update, bluez update, etc. <xnox> infinity: things that are not yet ready to go into Ubuntu Archive as an SRU. <infinity> Right, see, forks of stuff in the archive is a non-starter for me unless it's also renamed with appropriate conflicts, etc. <mdeslaur> how do we make sure an archive update doesn't then break those things? <xnox> it's a timing issue, rather than content. <infinity> Since the SRU team has no control over these archives, random forks just don't work. <xnox> mdeslaur: once updates/fixes are shipped in the OEM archives under SLAs, the OEM team works on upstreaming those fixes into devel and SRUing it. Such that after a period of time, none of the extra packages or fixes are needed. <mdeslaur> how do we make sure that actually happens? <vorlon> infinity: what if there were a tightly constrained policy regarding package versioning in the oem archives, and a requirement that the packages must be kept in the ppa (and maintained wrt security updates etc) until such time as the changes are merged back into the Ubuntu archive? <xnox> mdeslaur: meaning that next-LTS is shinny, but you are running bionic, so tough shit please wait 9m for things to start working =) <infinity> vorlon: If there was strict (and actually followed) policy in said archives, that would be fine. Unfortunately, we go back to oversight. Who's going to keep them in check? <xnox> mdeslaur: how do we make sure that actually happens => there is a good stick, if it doesn't happen OEMs don't renew contracts, and $$$ is gone, and the archive is gone too. <infinity> We make sure the primary archive is consistent because many people (some of whom are in this meeting) prevent developers from doing stupid things. <vorlon> infinity: aiui the ppas will all be public, not private; we could require as a precondition for exposing this in the ui that the responsible team also provide us archive checking tools to monitor? <xnox> mdeslaur: infinity: please note, that these archive are already enabled, and are shipped on ubuntu pre-installed certified devices. <mdeslaur> yeah but once we have the ppa, why would they pay to get stuff into the archive? <xnox> mdeslaur: infinity: thus they are in use by all Ubuntu Dell laptops, Lenovo Ubuntu Thinkpads etc. Unless one reinstalls or like removes those archives and downgrades. <infinity> xnox: Yes, I'm well aware, and they're also responsible for statements like "we can't upgrade OEM machines because they have no upgrade path" and other great oddities from the past. <mdeslaur> vorlon: I like the requirement that tools should be provided...and I'd also like some sort of policy that each package in the PPA needs to have an SRU bug filed immediately <infinity> xnox: If they want us to play nicely with them, this is a great opportunity to make sure they play nicely with us. <xnox> infinity: mdeslaur: another shiny thing, is BIOS settings, kernel cmdline parameters, and/or instructions on which BIOS settings must be set to be "good on linux, instead of good on windows" <infinity> And then maybe OEM install users can actually upgrade when everyone else does, not randomly lose OEM fixes to security fixes trumping them, etc. <xnox> i do agree there is currently little integration/oversight into what's currently in teh OEM archives overall. I.e. kind of like MoM on steroids, to see all the published packages & their version numbers, etc. <infinity> Anyhow, I'm not conceptually against an addition to ubuntu-drivers to make opting into OEM archives easier than Googling, typing, and praying. <infinity> But I want some indication that users who opt into that won't be opting into a situation worse than the one they left. <xnox> and an easy way to roll-back/downgrade back to vanilla, right?! <vorlon> (maybe keeping the prayer step wouldn't hurt) <xnox> infinity: to me, switching kernel flavours is scary. <infinity> Downgrading is something that we really shouldn't do, generally. <infinity> Which is why I prefer forked packages to updated ones. <xnox> yeah, i was thinking ppa-purge style, which can break things more than they were before. <infinity> s/forked/renamed/ <xnox> infinity: renamed, with metapackage pulling in a renamed one, whilst conflicting on the original name? <infinity> But if they can commit to making 0 packaging changes, and only doing code updates in those non-renamed packages, downgrading to archive versions should usually be harmless. <xnox> (just so i understand the logic, if it's bluez that is forked) * xnox conffiles <infinity> Renamed packages are a lot more effort to maintain, and unless someone like Timo is driving that, I fear for the quality coming out of the other end of the sausage machine. <infinity> So I wouldn't make it a requirement. <infinity> It's just that it works well when done right, cause they're easier to shuffle around. :P <xnox> if one used a point release bionic to install, one has linux-hwe kernel, whilst these OEM metapackages might try to upgrade to linux-oem kernel, which is of lower versions everything. <infinity> Right, I wouldn't allow this for bionic for that reason. * xnox is not sure how to deal with that, cause grub picks highest number betwen linux-hwe & linux-oem kernel images <infinity> In FF, linux-oem will be rolling with linux-hwe. <xnox> is linux-oem-oesp1 a rolling one? or just a newer one? <infinity> osp1 is a one-off that you should pretend doesn't exist. <infinity> In FF, linux-oem will be rolling with linux-hwe. <xnox> lolz <infinity> Almost like
{'channel': 'ubuntu-meeting-2', 'month': 10}