17:03 <kees> #startmeeting
17:03 <meetingology> Meeting started Tue Nov 25 17:03:12 2014 UTC.  The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
17:03 <meetingology> 
17:03 <meetingology> Available commands: action commands idea info link nick
17:03 <kees> [topic] action review
17:03 <kees> infinity to review and respond to MAAS SRU thread
17:03 <infinity> I also suspect I failed to send out minutes from the last meeting. :/
17:03 <infinity> And I definitely failed to do that ^ while on vacation.
17:04 <kees> if this MAAS thread continued, I didn't see it. Okay, moving on...
17:04 <kees> Riddell to improve the CFQ SRU paperwork to detail regression testing plans
17:04 <kees> Riddell: anything on this?
17:04 <Riddell> who what?
17:04 <slangasek> hi, sorry I'm late
17:04 <kees> Riddell: from a past TB meeting. I guess it was to outline testing for the CFQ proposal?
17:05 <Riddell> slangasek's regression test plans are on bug 1378789
17:05 <kees> okay, so should this be considered done?
17:05 <Riddell> well it still needs someone from ~ubuntu-sru to approve it
17:05 <Riddell> but that bit yes
17:05 <kees> okay, cool. thanks!
17:05 <slangasek> um
17:05 <kees> DONE: pitti to draft initial removal-as-an-SRU policy document with a less lousy name than the one used in this action
17:05 <slangasek> the test case in the bug description doesn't seem to have been updated?
17:05 <kees> slangasek: ?
17:06 <slangasek> that's where the test plan needs to be recorded
17:06 <mdeslaur> where is the test for kubuntu?
17:08 <kees> Riddell: thoughts?
17:08 <Riddell> I've updated bug 1378789 now
17:08 <Riddell> with test case for kubuntu and unity
17:09 <slangasek> ok, looks good to me
17:10 <kees> great, thanks!
17:11 <kees> [topic] Discuss/vote on proposal for removals in SRUs https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves
17:11 <kees> anything new to discuss here?
17:11 <kees> seems like the discuss on the list died down.
17:11 <mdeslaur> I just had a comment on removing it from the dev release
17:12 <mdeslaur> I had mentioned the blacklist, but cjwatson said removing it was enogh
17:12 <mdeslaur> enough
17:12 <mdeslaur> should making sure the package gets removed from the dev release be part of the plan?
17:12 <kees> well, the case that isn't handled automatically is one where it's reintroduced...
17:13 <slangasek> I think it should be part of the plan
17:13 <kees> it seems like some cases that might be good, and in others bad. maybe "review removed packages when dev opens"?
17:13 <slangasek> kees: what do you mean by "reintroduced"?
17:13 <mdeslaur> kees: if it gets removed from the dev release, it never gets synced back
17:13 <kees> slangasek: tor, for example, was removed, then added back, and then removed again
17:13 <slangasek> but was that a manual reintroduction?
17:14 <kees> yes
17:14 <slangasek> ok
17:14 <Riddell> bug 1384355 has just been marked verification-done "
17:14 <Riddell> ownCloud should be removed"
17:15 <slangasek> seems like the NEW queue would ideally expose information to the AAs that a package was once present but was removed
17:15 <slangasek> that would be preferable over maintaining a blacklist by hand
17:15 <kees> mdeslaur, slangasek: so, should we have the step, or are the automatic mechanisms sufficient?
17:15 <kees> seems to me like the existing mechanism is good enough here.
17:16 <slangasek> if we're having packages removed/added/removed, it sounds to me like the current mechanism isn't sufficient
17:17 <mdeslaur> well, it looks like tor got added back because someone volunteered to maintain it
17:17 <kees> right.
17:17 <mdeslaur> if that's the case, then adding it back is probably acceptable
17:17 <kees> and then they vanished
17:17 <mdeslaur> as long as we don't add stuff back by _mistake_
17:17 <kees> and that hasn't happened.
17:18 <kees> I'm hoping to avoid adding this step because it means us finding a workflow to attach it to. the existing stuff already keeps removed stuff out.
17:18 <mdeslaur> the sru tracking bug can also cover removing it from the dev release
17:19 <infinity> I don't recall things being "accidentally" re-added in the past.  Intentionally, yes, though intent can be any core-dev or MOTU.
17:19 <mdeslaur> so I guess I'm ok with it as-is, as long as we don't sync stuff back by mistake
17:19 <kees> should we add a note that says "when removed from stable releases, it must be removed from dev too" ?
17:19 <slangasek> infinity, mdeslaur: I guess my feeling is that if the package was neutered via SRU, it needs a higher barrier to re-entry than just "someone volunteers to maintain it"
17:20 <mdeslaur> kees: well, maybe not always...perhaps we'd want to remove an ancient version in precise, but keep the recent versions in trusty+, for example
17:20 <slangasek> kees: yes
17:20 <kees> heh
17:20 <slangasek> hmm :)
17:20 <infinity> slangasek: I'm not inclined to disagree with that, I'm just not sure what the best technical solution to that problem would be.
17:20 <slangasek> infinity: the AA should know at NEW review time that this was a previously-removed package? :)
17:20 <kees> "When removed from a stable release, it may need removal from the devel release as well, depending on the justification for removal."
17:21 <slangasek> kees: +1
17:21 <mdeslaur> kees: +1
17:21 <stgraber> +1
17:21 <infinity> kees: Definitely needs to be worded more as "removal from all releases (including the development release) should be examined using the same criteria as the removal from the stable release in question".
17:21 <infinity> kees: Oh, hey, you just said something similar. :)
17:22 <infinity> kees: I could see a case where, say, only the lucid package was an unsupportable mess, but the rest are fine, or whatever.
17:22 <kees> right
17:22 <slangasek> (solution: remove lucid)
17:22 <infinity> slangasek: Working on it!
17:22 * infinity turns the planet faster.
17:23 <slangasek> it'll be done in another year or so, right?
17:23 <infinity> slangasek: 5 months!
17:23 <kees> so.. this isn't really a "removal", right, this is an "empty with NEWS overwrite"...
17:24 <infinity> kees: Right, it's that in stable releases, but should be a hard removal in devel releases if appropriate.
17:24 * slangasek double-checks that the critical debconf note is still a requirement :)
17:24 <infinity> slangasek: It is.
17:24 <kees> https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves <- updated
17:25 <kees> okay, so this leaves us with only "should we do something more dramatic besides dropping from devel?"
17:25 <infinity> kees: I suppose I could also see cases where continuing to include the empty package with a NEWS/note about how to obtain the upstream-blessed version isn't the worst idea ever, either.  But Google can serve that purpose as well as we can, so maybe not a case worth mentioning.
17:26 <ScottK> Except that we (via an updated package) just messed with the system that had it installed.  We owe an explanation.
17:26 <kees> ScottK: right, that happens on stable, but not devel.
17:26 <kees> on devel, it's just gone.
17:26 <kees> (uninstallable)
17:26 <infinity> slangasek: So, how would you envision this queue enhacement working?  Maybe just have the queue flag if the source exists in any previous release, but not the current one?
17:27 <slangasek> infinity: if the package was previously removed manually, it could show the removal reason?
17:27 <infinity> slangasek: Well, we have no concept of how/why a package was removed.  It was removed if it was removed.  So, it would be the exist/not-exist check.
17:27 <slangasek> infinity: um
17:27 <slangasek> infinity: if you remove a package, you have to give a removal reason :)
17:28 <infinity> slangasek: But then, sure, we could show the -m
17:28 <slangasek> right
17:28 <infinity> slangasek: No, I was responding to your "the package was previously removed manually", that's not something we know. :)
17:28 <slangasek> well, ok
17:28 <slangasek> but we can filter out the autogenerated -m
17:28 <slangasek> at least theoretically :)
17:28 <slangasek> anyway
17:29 <slangasek> I don't think that needs to block the plan overall
17:29 <slangasek> should we just take an action to follow up on that?
17:29 <infinity> slangasek: Want to file a bug at lp.net/launchpad requesting such a feature?
17:29 <kees> what action can be taken then?
17:29 <infinity> kees: I think we should probably vote on the current wording and if we include it in the larger SRU doc.
17:30 <kees> [action] slangasek to file a bug against LP to request showing manual package removal reason
17:30 * meetingology slangasek to file a bug against LP to request showing manual package removal reason
17:30 <infinity> kees: Oh, might be worth noting that removal history should be documented in the list given at the bottom of that page. :P
17:32 <slangasek> bug #1396266
17:32 <kees> [vote] Approve wording on SRU Removals: https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves
17:32 <meetingology> Please vote on: Approve wording on SRU Removals: https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves
17:32 <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:32 <kees> +1
17:32 <meetingology> +1 received from kees
17:32 <stgraber> +1
17:32 <meetingology> +1 received from stgraber
17:32 <slangasek> +1
17:32 <meetingology> +1 received from slangasek
17:32 <infinity> kees: I might also prefer something like "This is a last-step resort, it's always preferable to fix a package, rather than drop it, but if no one can step forward to do so... $PROCESS"
17:32 <mdeslaur> +1
17:32 <meetingology> +1 received from mdeslaur
17:32 <infinity> +1
17:32 <meetingology> +1 received from infinity
17:32 <slangasek> fwiw on reflection we don't need to distinguish between auto and manual removals... source packages are never truly autoremoved from LP AFAIK
17:32 <kees> [endvote]
17:32 <meetingology> Voting ended on: Approve wording on SRU Removals: https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves
17:32 <meetingology> Votes for:5 Votes against:0 Abstentions:0
17:32 <meetingology> Motion carried
17:33 <kees> slangasek: okay, cool. and since the bug has been opened, I'll drop the action. :)
17:33 <infinity> The part where only two people appear to have used this process so far is nice, but I don't want to see it become a habit as we ratify it as an official thing.
17:33 <slangasek> what ever happened to the bitcoin request?
17:33 <kees> infinity: right. is the language "in rare cases" not sufficient? I felt that was good enough when I first reviewed this (I had the same concern).
17:33 <slangasek> did that not use this process?
17:34 <infinity> kees: I think "in rare cases" spells it out for people who already know why they should be rare, but is a bit opaque to the world, who all think their case is rare.
17:34 <slangasek> https://launchpad.net/ubuntu/+source/bitcoin/0.3.24~dfsg-1ubuntu0.2 it sure did
17:34 <infinity> Well, look at that.  Three times!
17:35 <mdeslaur> oh, huh
17:35 <infinity> And that has neither NEWS nor a debconf note. :/
17:35 <infinity> So just a silent neutering.
17:36 <slangasek> heh
17:36 <kees> infinity: how about "While it is always preferable to fix a package, rather than drop it, there are rare cases when a universe package becomes actively detrimental ..."
17:36 <infinity> kees: That works for me.
17:36 <kees> any object to that change, post-vote? :)
17:36 <kees> I've added bitcoin to the list now too
17:36 <slangasek> no objection
17:36 <mdeslaur> no objection from me
17:37 <slangasek> infinity: there is too a debian/NEWS
17:37 <infinity> I think that's strong enough wording to avoid my concern for this becoming a case of every upstream EVAR strongarming us into upgrade-or-delete maintenance of their pet project.
17:38 <kees> [topic] mailing list archive
17:38 <infinity> slangasek: Oh, so there is.  It was the same content as changelog, so I skipped right past it in the diff.
17:38 <kees> the only thing I see unaddressed here is Docker, but that seems to be continuing on the list.
17:39 <kees> I don't see anything from the ML that needs IRC attention. Anyone see otherwise?
17:39 <slangasek> (debconf note still missing, but this was long enough ago that I don't think there's any point in enforcing the policy retroactively)
17:39 <infinity> The docker thing might deserve some real-time discussion.
17:40 <kees> I wanted functional testing for stable update regressions, pat said she'd check on upstream, but nothing new yet.
17:40 <infinity> Not necessarily docker itself, but that I see a pattern of people wanting to keep shipping new upstreams, and I wonder if we need to be actively caring more deeply about this, or if I need to be caring less, or what. :P
17:40 <infinity> I know when the docker-in-trusty thing first came to me, the promise was that if I move the /usr/bin/docker binary around and let them SRU docker 1.0, they'd stick with 1.0.x for the life of trusty.
17:41 <infinity> And now the goalposts have shifted.
17:41 <kees> Well, I have my own not entirely helpful solution for that case: upgrade Ubuntu every 6 months. :P
17:41 <infinity> I suspect it's a sabdfl thing, but that thread doesn't seem to mention a sabdfling, and "we want to push a bunch of new upstram versions into stable releases" isn't a standard Ubuntu thing.
17:42 <infinity> Except for the HWE stack, which I fear set an unfortunate pseudo-precedent in a lot of people's minds.
17:42 <kees> these kinds of things have always been Cloudy packages...
17:42 <ScottK> Of course sabdfling has to be explicit and direct.
17:42 <mdeslaur> what happens with security issues? ie: docker pre-1.3.2 right now allow host privilege escalation...
17:42 <slangasek> mdeslaur: we trigger the SRU removal process? ;)
17:42 <mdeslaur> hehehe
17:42 <infinity> mdeslaur: Are there upstream fixes for that?  I was also assured that 1.0.x was an upstream supported release for a good while. :P
17:42 <kees> +1
17:43 <mdeslaur> infinity: yes, "upgrade to 1.3.2"
17:43 <infinity> mdeslaur: Ugh.
17:43 <infinity> Also, ugh.
17:43 <kees> the sign of a mature and trusted upstream.
17:43 <slangasek> docker is problematic because it's fast-moving, mostly of interest on servers (--> LTS), and doesn't fit any of the other models we've come up with for this (e.g. the cloud archive)
17:43 <infinity> kees: I assume the irony of that comment in light of who signs your paycheque isn't lost on you. :)
17:44 <slangasek> hmm
17:44 <kees> infinity: I live in a sea of irony.
17:44 <mdeslaur> heh
17:44 <slangasek> so if 1.0.x is not actually upstream-supported, I think it's important to revisit the assumptions of the original exception
17:44 <infinity> Right.
17:44 <slangasek> before we go granting further exceptions
17:45 <slangasek> mdeslaur: sounds like you're in a position to drive that since you have the facts at your disposal?
17:45 <kees> so, fundamentally, I don't object to major version updates as long as it doesn't break people. To "prove" this, I want to see extensive funcitonal tests, and upstreams rarely have this.
17:45 <mdeslaur> slangasek: yes, let me investigate a bit more to get my facts straight and I'll respond to the thread
17:45 <kees> as such, I think it's the responsibility of the requestor to produce such tests if they want the new versions.
17:45 <mdeslaur> kees: add an action item for me, please
17:45 <infinity> So, I guess there are two things to look at here.  One, is docker perhaps a candidate for a minor-release-exception, instead of a micro-release-exception, or maybe even a chrome/firefox-style "we trust them implicitly, screw it" exception.
17:46 <kees> [action] mdeslaur to gather facts on docker versions and respond to the thread
17:46 * meetingology mdeslaur to gather facts on docker versions and respond to the thread
17:46 <infinity> And two, the "ship multiple upstream versions, whee" thing that seems to be becoming the server team's favourite workaround.
17:46 <slangasek> kees: I believe we know that new upstream versions of docker are proven *to* break people if you try to just do an in-place upgrade
17:46 <infinity> slangasek: Oh, how very fun.
17:46 <slangasek> that's why the proposal is to have them available under separate package names
17:46 <kees> slangasek: oh great. then yeah, shipping docker1.3 becomes the "solution"?
17:47 <slangasek> seems so
17:47 <infinity> slangasek: But the multiple packages option helps no one if the older ones are unsupported and insecure.
17:47 <slangasek> OTOH I don't have a source for the above claim, so maybe I'm just reading too much between the lines
17:47 <kees> well, that's ugly, but I can't say I'm opposed to it.
17:47 <slangasek> infinity: correct
17:47 <slangasek> clearly the right solution is an app store on the server
17:47 <kees> right, there's that part. *hold face*
17:48 <infinity> slangasek: Because an app store would magically migrate users in a way that a package upgrade can't? :P
17:48 <kees> infinity: I think that was a sarcastic suggestion :)
17:48 <infinity> kees: I read it as sarcasm, but chose to respond straight.
17:48 <slangasek> infinity: an app store would get us out of the position of having to adjudicate the relationship between the upstream and the user :)
17:48 <kees> actual LOL
17:48 <slangasek> no, it wasn't sarcastic
17:48 <infinity> And yes, that's why.
17:48 <infinity> It means it's upstream's fault when they break upgrades, not ours.
17:48 <infinity> In theory.
17:49 <kees> okay, clearly we should take this to the ML, which mdeslaur has an action for already.
17:49 <slangasek> if docker weren't in Ubuntu, we wouldn't have to try to make it fit Ubuntu policies
17:49 <infinity> I don't believe that theory holds true in practice on a platform like ours.
17:49 <infinity> But I could be wrong.
17:49 <kees> [topic] AOB
17:49 <kees> any surprise topics?
17:49 <infinity> I'm pregnant!
17:50 <kees> IT'S NOT MINE
17:50 <infinity> Are you sure?
17:50 <mdeslaur> heh
17:50 <kees> [topic] next chair
17:50 <kees> looks like mdeslaur ?
17:50 <mdeslaur> fine by me!
17:50 <infinity> Yep.
17:50 <kees> boooom, done.
17:51 <kees> thanks everyone!
17:51 * infinity waves.
17:51 <kees> #endmeeting