[16:04] <mdeslaur> sorry, running late
[16:50] <mdeslaur> ah, timezone fail
[17:00]  * slangasek waves
[17:00] <pitti> hello
[17:00] <mdeslaur> \o
[17:00] <infinity> o/
[17:00]  * stgraber waves
[17:00] <kees> \o
[17:00] <mdeslaur> did london move, or did the time change there? :P
[17:00] <infinity> And the gang's all here!
[17:01] <pitti> mdeslaur: DST change last weekend
[17:01] <stgraber> mdeslaur: europe DST starts a week before north american DST
[17:01] <pitti> and ends three weeks after
[17:01] <infinity> #startmeeting
[17:01] <meetingology> Meeting started Tue Oct 28 17:01:27 2014 UTC.  The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:01] <meetingology> Available commands: action commands idea info link nick
[17:01] <pitti> (end of Oct in EU, start of Oct in US)
[17:01] <slangasek> strange that I didn't see anyone mentioning this DST change on lists
[17:01] <infinity> [TOPIC] Action review
[17:02] <infinity> Oh, meetingology doesn't have topic rights here, does it?  Silly.
[17:03] <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.
[17:03] <infinity> Riddell: Are you here to discuss the two things you wanted to hit early in the meeting before you have to leave?
[17:04] <infinity> *tick, tick, tick*
[17:04] <infinity> Right, we'll leave his items until he pops up.
[17:04] <pitti> well, we can start the owncloud thing
[17:04] <pitti> which seems like a no-brainer to me
[17:05] <pitti> I responded to the bug and the ML
[17:05] <infinity> pitti: No-brainer, as in you're +1 on uploading empty packages?
[17:05] <pitti> yes
[17:05] <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
[17:06] <mdeslaur> especially since upstream asked
[17:06] <pitti> it's ugly, but still better than leaving it vulnerable
[17:06] <infinity> [VOTE] replace owncloud packages with empty stubs, since no one's willing to maintain it
[17:06] <meetingology> Please vote on: replace owncloud packages with empty stubs, since no one's willing to maintain it
[17:06] <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)
[17:06] <infinity> +1
[17:06] <meetingology> +1 received from infinity
[17:06] <pitti> +1
[17:06] <meetingology> +1 received from pitti
[17:06] <mdeslaur> +1
[17:06] <meetingology> +1 received from mdeslaur
[17:06] <stgraber> +1
[17:06] <meetingology> +1 received from stgraber
[17:06] <slangasek> hmm
[17:06] <kees> +1
[17:06] <meetingology> +1 received from kees
[17:07] <slangasek> well, I would've appreciated a bit of discussion time here
[17:07] <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.
[17:07]  * pitti is running the owncloud debs from upstream, they work reasonably well and get updated
[17:07] <slangasek> infinity: and is there a debconf notice at install time?
[17:07] <infinity> slangasek: But feel free to vote FD. ;)
[17:07] <pitti> not in the current upload
[17:07] <kees> can we document the "empty upload" policy so we can reuse it when we hit these things again?
[17:08] <pitti> FWIW, I was voting about the general "replace them with empty stub", not the precise implementation; debconf seems fine to me, too
[17:08] <infinity> slangasek: I'd think a double-whammy of NEWS.Debian and a debconf note might help.
[17:08] <slangasek> I do think this is the right principle
[17:08] <slangasek> but it's important that the user who upgrades knows what's what
[17:08] <infinity> Happy to have someone document one of both of those as a requirement in the bug to go with our decision.
[17:08] <slangasek> so on that basis, +1
[17:08] <slangasek> +1
[17:08] <meetingology> +1 received from slangasek
[17:09] <infinity> s/one of/one or/
[17:09] <infinity> [ENDVOTE]
[17:09] <meetingology> Voting ended on: replace owncloud packages with empty stubs, since no one's willing to maintain it
[17:09] <meetingology> Votes for:6 Votes against:0 Abstentions:0
[17:09] <meetingology> Motion carried
[17:10] <AnybodyElse> (Thanks - upstream guy here. We had A LOT of users that installed the outdated Universe package.)
[17:10] <infinity> slangasek: Want to follow up to https://bugs.launchpad.net/ubuntu/+source/owncloud/+bug/1384355 with the "please add a debconf note" mention?
[17:10] <mdeslaur> kees: the policy on the technical way to do it, or on when it's appropriate to do
[17:10] <slangasek> will do
[17:10] <infinity> mdeslaur: The former, I'd think.
[17:10] <infinity> mdeslaur: "Appropriate" is always a case-by-case thing.
[17:10] <kees> mdeslaur: I meant the former, but probably we need both.
[17:11] <kees> and for the latter, yeah, say "case-by-case" but give past examples since it's so rare (Java, e.g.)
[17:11] <mdeslaur> AnybodyElse: hi!
[17:11] <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.
[17:11]  * AnybodyElse waves back to mdeslaur :)
[17:11] <slangasek> I don't think "no distro maintainers" is sufficient cause to say that it's actively harmful to users
[17:12] <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
[17:12] <infinity> slangasek: Right, "no distro maintainers, and it's woefully out of date with security issues" blah blah.
[17:12] <slangasek> yes
[17:12] <infinity> slangasek: Hence my "case-by-case" statement.
[17:12] <slangasek> if we were going to leave this to be case-by-case, there's no reason to involve the TB
[17:12] <slangasek> a policy should be an actual policy :)
[17:12] <infinity> Fair point.
[17:13] <slangasek> anyway, commented on the bug
[17:13] <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.
[17:13] <slangasek> is someone taking the action to draft a policy?
[17:14] <pitti> that should go on https://wiki.ubuntu.com/StableReleaseUpdates, right?
[17:14] <slangasek> yes, I would say so
[17:14] <infinity> pitti: Ultimately, I'd think it would be there, or linked from there.
[17:14] <pitti> or a subpage; at least under that domain
[17:14] <infinity> https://wiki.ubuntu.com/StableReleaseUpdates/Removals perhaps.
[17:14] <pitti> yeah, and linking from /SRU; although it wouldn't be very long, maybe two paragraphs
[17:15] <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?
[17:15] <pitti> ^ or on the list
[17:15] <slangasek> "maybe two paragraphs" to me says it shouldn't be a subpage, but ymmv and doesn't need bikeshedding
[17:16] <infinity> pitti: Well, it could be a removal policy in general, so could grow.  So, security issues, like owncloud, IP takedown issues, etc.
[17:16] <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 :)
[17:16] <infinity> pitti: Well, if you're volunteering, I doubt kees will assert ownership of the idea. :P
[17:16] <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
[17:17] <pitti> such things are hard to pinpoint in a policy
[17:17] <infinity> [ACTION] pitti to draft initial removal-as-an-SRU policy document with a less lousy name than the one used in this action.
[17:17] <meetingology> ACTION: pitti to draft initial removal-as-an-SRU policy document with a less lousy name than the one used in this action.
[17:17] <mdeslaur> does the SRU team remain authoritative on empty package SRUs?
[17:18] <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
[17:18] <mdeslaur> infinity: ok, that's fine with me
[17:20] <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.
[17:20]  * mdeslaur nods
[17:20] <infinity> Anyhow.  Skipping along.  Going to bounce the CFQ thing until Riddell pops up.
[17:20] <pitti> well, the SRU team is bound by the policy in https://wiki.ubuntu.com/StableReleaseUpdates
[17:21] <infinity> pitti: They write the policy, so "bound" is a curious term.
[17:21] <pitti> infinity: I think it was actually written by the TB
[17:21] <pitti> and all changes certainly were approved by the TB
[17:21] <infinity> pitti: Well, I've certainly amended it a lot when I wasn't on the TB. :P
[17:22] <infinity> Anyhow, a governance discussion seems like it would take the whole meeting slot, and we have a busy week for once.
[17:22] <pitti> CFQ> not sure if there's much else to discuss; it's rock <-> that SRU <-> hard place
[17:22] <infinity> [TOPIC] Dismantling the ARB
[17:23] <infinity> stgraber: Care to wax poetical on this topic?
[17:23] <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
[17:23] <stgraber> sure
[17:23] <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
[17:24] <stgraber> I believe it's now time to just kill it entirely and remove the repository in 15.04
[17:24]  * kees sharpens the axe
[17:24] <pitti> oh, so it's practically non-existing already anyway?
[17:24] <infinity> pitti: Right, it's dead, it just needs to be told it's dead.
[17:24] <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)
[17:24] <pitti> kees: axe? I thought a wooden spile through the heart is better for zombies?
[17:25] <kees> hehe
[17:25] <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?
[17:25] <kees> I think spikes are for vampires
[17:25] <mdeslaur> stgraber: perhaps I'm confused, but isn't there activity in the weekly reports?
[17:25] <stgraber> nope
[17:25] <stgraber> you're confusing this with the commercial app stuff I suspect
[17:26] <mdeslaur> oh, yes, I am
[17:26] <mdeslaur> I keep confusing those two
[17:26] <mdeslaur> sorry, please ignore me
[17:27] <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?
[17:27] <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)
[17:27] <infinity> Well, release-upgrader for upgrades, and installers for new installs.
[17:27] <slangasek> infinity: I think it's clear that this is what needs to be done, yes
[17:28] <slangasek> infinity: just make sure this decision turns into a bug report :)
[17:28] <infinity> Right, do we need a formal vote on the undelegation of the team?
[17:28] <stgraber> yeah
[17:28] <infinity> [VOTE] undelegate the ARB and remove the team from LP
[17:28] <meetingology> Please vote on: undelegate the ARB and remove the team from LP
[17:28] <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)
[17:29] <infinity> +11
[17:29] <meetingology> +11 received from infinity
[17:29] <stgraber> +1
[17:29] <meetingology> +1 received from stgraber
[17:29] <mdeslaur> +1
[17:29] <meetingology> +1 received from mdeslaur
[17:29] <slangasek> +1
[17:29] <meetingology> +1 received from slangasek
[17:29] <pitti> +1
[17:29] <meetingology> +1 received from pitti
[17:29] <slangasek> +1!!
[17:29] <meetingology> +1!! received from slangasek
[17:29] <kees> +1
[17:29] <meetingology> +1 received from kees
[17:29] <infinity> [ENDVOTE]
[17:29] <meetingology> Voting ended on: undelegate the ARB and remove the team from LP
[17:29] <meetingology> Votes for:6 Votes against:0 Abstentions:0
[17:29] <meetingology> Motion carried
[17:29]  * slangasek one-ups infinity
[17:29] <pitti> infinity has chair has 11 times the voting power??
[17:29] <slangasek> because 1-factorial-factorial is better than 11
[17:29] <infinity> pitti: According to the bot, no.
[17:30] <infinity> stgraber: Can you file a bug report on whatever components you can think this affects?
[17:30] <infinity> stgraber: u-r-u, apt-setup, ubiquity, livecd-rootfs, maybe curtin...
[17:30] <pitti> infinity: (j/k)
[17:30] <infinity> pitti: I was curious to see if it would tally it oddly, but I guess it's smarter (or, realistically, dumber) than that.
[17:31] <stgraber> infinity: sure. I'll also take care of killing off the team and any documentation I can find
[17:31] <infinity> stgraber: \o/
[17:31] <pitti> rest in peace, extras.u.c., and be replaced click apps..
[17:31] <mdeslaur> stgraber: aim for the head
[17:31] <infinity> [TOPIC] Community bugs: 0
[17:31] <pitti> "with"
[17:32] <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?
[17:32] <infinity> Should we be advertising a more friendly "hey, you can assign bugs to us when they need guidance" stance?
[17:33] <slangasek> is Riddell's SRU escalation not a "community bug"?
[17:33] <infinity> Oh, true, it's just not in the search link. :P
[17:33] <slangasek> I guess technically there wasn't a bug report assigned to us, sure
[17:33] <slangasek> but I don't think we care about the escalation vector, really
[17:34] <pitti> I can remember only one community bug ever..
[17:34] <infinity> Alright, maybe it's working as designed, then.
[17:34] <infinity> [TOPIC] Mailing list review
[17:34] <infinity> Which I think probably brings us full circle to CFQ.
[17:34]  * slangasek nods
[17:35] <infinity> Does anyone have any new opinions on that that they haven't voiced on the list?
[17:36] <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?
[17:36] <pitti> but slangasek's test plan looked fairly comprehensive
[17:36] <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.
[17:36] <infinity> But maybe that fear is silly, as multi-DE installs are hugely uncommon, and reserved for the nerdy.
[17:37] <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"
[17:37] <slangasek> currently the SRU test case shown is the original one, which is incomplete
[17:38] <infinity> Riddell: Since you seem to still be idle, when you get back and read backscroll, can you address Steve's bug paperwork concerns?
[17:38] <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
[17:38] <infinity> Riddell: Thanks in advance. :P
[17:38] <infinity> slangasek: Sure, but I'm not sure layering like that is a thought exercise worth getting into.
[17:39] <slangasek> not sure what you mean
[17:39] <infinity> slangasek: Ubuntu in a VM performs differently if the host is Ubuntu or RHEL too.  Oh well.
[17:39] <slangasek> I'm not talking about layering
[17:39] <slangasek> I'm talking about "if you run a VM on kubuntu you will be in pain"
[17:39] <slangasek> as in, your desktop experience will regress
[17:39] <mdeslaur> no, heavy disk io, whether created by a VM that's running, or simply copying files off of a USB disk
[17:39] <infinity> slangasek: I think "you will be in pain" is an exaggeration, but this is where some good testing is a solid plan.
[17:40] <slangasek> maybe I have a low pain tolerance ;)
[17:40] <slangasek> anyway, actionability here - next step is for the Kubuntu devs to lay out their explicit test plan in the SRU bug?
[17:40] <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".
[17:41] <infinity> In a broad sense.  Obviously not in any willy nilly SRU, hence the discussion.
[17:41] <slangasek> well, I think the SRU team has a duty to protect Kubuntu users from regressions too
[17:42] <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?
[17:42] <slangasek> infinity: can you just [ACTION] it and send out minutes? :-)
[17:42] <infinity> Maaaybe.
[17:42] <slangasek> I mean [ACTION] Riddell, not me
[17:43] <infinity> [ACTION] Riddell to improve the CFQ SRU paperwork to detail regression testing plans
[17:43] <meetingology> ACTION: Riddell to improve the CFQ SRU paperwork to detail regression testing plans
[17:44] <infinity> [TOPIC] Next chair
[17:44] <infinity> Should be kees, unless he's got other plans.
[17:44] <infinity> kees: ^
[17:45] <infinity> Hrm, next meeting would be Nov 11.  A lot of countries take that off.
[17:45] <kees> yup
[17:45] <kees> oh?
[17:45] <infinity> Should we defer for a week, or jiggle it around?
[17:45] <slangasek> "a lot of countries"?
[17:45] <kees> oh, so it is.
[17:45] <infinity> slangasek: Well, some.  I'm not sure who. :P
[17:45] <slangasek> oh, right
[17:45] <kees> "a lot of the board are in country that takes it off"
[17:45] <slangasek> we didn't actually invent that date, we just rebranded it ;-)
[17:46] <kees> I vote to skip it.
[17:46] <pitti> there's still the ML
[17:46] <pitti> for discussing CFQ etc.
[17:46] <kees> I can run the 25th meeting, then?
[17:46] <infinity> [VOTE] Skip Nov 11 meeting, so people can buy poppies and be appropriately respectful
[17:46] <meetingology> Please vote on: Skip Nov 11 meeting, so people can buy poppies and be appropriately respectful
[17:46] <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)
[17:46] <infinity> +1
[17:46] <meetingology> +1 received from infinity
[17:46] <kees> +1
[17:46] <meetingology> +1 received from kees
[17:46] <mdeslaur> +1
[17:46] <meetingology> +1 received from mdeslaur
[17:47] <stgraber> +1
[17:47] <meetingology> +1 received from stgraber
[17:47] <slangasek> +1
[17:47] <meetingology> +1 received from slangasek
[17:47] <infinity> Right, the 1s have it.
[17:47] <infinity> [ENDVOTE]
[17:47] <meetingology> Voting ended on: Skip Nov 11 meeting, so people can buy poppies and be appropriately respectful
[17:47] <meetingology> Votes for:5 Votes against:0 Abstentions:0
[17:47] <meetingology> Motion carried
[17:47] <infinity> kees: You've got the 25th, then.
[17:47] <slangasek> (poppies?  I thought this day was for celebrating heroes, not heroin)
[17:47] <infinity> slangasek: Canadians celebrate by getting high.
[17:48] <infinity> [TOPIC] AOB
[17:48] <slangasek> that seems like a truism
[17:48] <infinity> Anything else?
[17:48] <pitti> nothing from me
[17:48] <slangasek> not here
[17:48] <infinity> slangasek: It's symbolic of the poppies that grow among the graves in Flanders Fields.
[17:48] <slangasek> huh
[17:49] <slangasek> learn something new
[17:49]  * mdeslaur learns something new
[17:49] <infinity> #endmeeting
[17:49] <meetingology> Meeting ended Tue Oct 28 17:49:36 2014 UTC.
[17:49] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2014/ubuntu-meeting-2.2014-10-28-17.01.moin.txt
[17:50] <kees> thanks!
[17:50] <slangasek> thanks!
[17:50] <mdeslaur> thanks everyone!
[17:50] <stgraber> thanks!
[17:50] <pitti> thanks everyone