/srv/irclogs.ubuntu.com/2014/11/25/#ubuntu-meeting-2.txt

kees\o16:59
* stgraber waves16:59
mdeslaur\o17:00
keesslangasek: ready?17:01
infinityI'm sort of here, and sort of recovering from vacation (done) and a flu (ongoing), so don't expect intelligent debate. :P17:02
keesheh :)17:02
kees#startmeeting17:03
meetingologyMeeting started Tue Nov 25 17:03:12 2014 UTC.  The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology.17:03
meetingologyAvailable commands: action commands idea info link nick17:03
kees[topic] action review17:03
keesinfinity to review and respond to MAAS SRU thread17:03
infinityI also suspect I failed to send out minutes from the last meeting. :/17:03
infinityAnd I definitely failed to do that ^ while on vacation.17:03
keesif this MAAS thread continued, I didn't see it. Okay, moving on...17:04
keesRiddell to improve the CFQ SRU paperwork to detail regression testing plans17:04
keesRiddell: anything on this?17:04
Riddellwho what?17:04
slangasekhi, sorry I'm late17:04
keesRiddell: from a past TB meeting. I guess it was to outline testing for the CFQ proposal?17:04
Riddellslangasek's regression test plans are on bug 137878917:05
keesokay, so should this be considered done?17:05
Riddellwell it still needs someone from ~ubuntu-sru to approve it17:05
Riddellbut that bit yes17:05
keesokay, cool. thanks!17:05
slangasekum17:05
keesDONE: pitti to draft initial removal-as-an-SRU policy document with a less lousy name than the one used in this action17:05
slangasekthe test case in the bug description doesn't seem to have been updated?17:05
keesslangasek: ?17:05
slangasekthat's where the test plan needs to be recorded17:06
mdeslaurwhere is the test for kubuntu?17:06
keesRiddell: thoughts?17:08
RiddellI've updated bug 1378789 now17:08
Riddellwith test case for kubuntu and unity17:08
slangasekok, looks good to me17:09
keesgreat, thanks!17:10
kees[topic] Discuss/vote on proposal for removals in SRUs https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves17:11
keesanything new to discuss here?17:11
keesseems like the discuss on the list died down.17:11
mdeslaurI just had a comment on removing it from the dev release17:11
mdeslaurI had mentioned the blacklist, but cjwatson said removing it was enogh17:12
mdeslaurenough17:12
mdeslaurshould making sure the package gets removed from the dev release be part of the plan?17:12
keeswell, the case that isn't handled automatically is one where it's reintroduced...17:12
slangasekI think it should be part of the plan17:13
keesit seems like some cases that might be good, and in others bad. maybe "review removed packages when dev opens"?17:13
slangasekkees: what do you mean by "reintroduced"?17:13
mdeslaurkees: if it gets removed from the dev release, it never gets synced back17:13
keesslangasek: tor, for example, was removed, then added back, and then removed again17:13
slangasekbut was that a manual reintroduction?17:13
keesyes17:14
slangasekok17:14
Riddellbug 1384355 has just been marked verification-done "17:14
RiddellownCloud should be removed"17:14
slangasekseems like the NEW queue would ideally expose information to the AAs that a package was once present but was removed17:15
slangasekthat would be preferable over maintaining a blacklist by hand17:15
keesmdeslaur, slangasek: so, should we have the step, or are the automatic mechanisms sufficient?17:15
keesseems to me like the existing mechanism is good enough here.17:15
slangasekif we're having packages removed/added/removed, it sounds to me like the current mechanism isn't sufficient17:16
mdeslaurwell, it looks like tor got added back because someone volunteered to maintain it17:17
keesright.17:17
mdeslaurif that's the case, then adding it back is probably acceptable17:17
keesand then they vanished17:17
mdeslauras long as we don't add stuff back by _mistake_17:17
keesand that hasn't happened.17:17
keesI'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
mdeslaurthe sru tracking bug can also cover removing it from the dev release17:18
infinityI don't recall things being "accidentally" re-added in the past.  Intentionally, yes, though intent can be any core-dev or MOTU.17:19
mdeslaurso I guess I'm ok with it as-is, as long as we don't sync stuff back by mistake17:19
keesshould we add a note that says "when removed from stable releases, it must be removed from dev too" ?17:19
slangasekinfinity, 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:19
mdeslaurkees: well, maybe not always...perhaps we'd want to remove an ancient version in precise, but keep the recent versions in trusty+, for example17:20
slangasekkees: yes17:20
keesheh17:20
slangasekhmm :)17:20
infinityslangasek: 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
slangasekinfinity: 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:20
slangasekkees: +117:21
mdeslaurkees: +117:21
stgraber+117:21
infinitykees: 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
infinitykees: Oh, hey, you just said something similar. :)17:21
infinitykees: I could see a case where, say, only the lucid package was an unsupportable mess, but the rest are fine, or whatever.17:22
keesright17:22
slangasek(solution: remove lucid)17:22
infinityslangasek: Working on it!17:22
* infinity turns the planet faster.17:22
slangasekit'll be done in another year or so, right?17:23
infinityslangasek: 5 months!17:23
keesso.. this isn't really a "removal", right, this is an "empty with NEWS overwrite"...17:23
infinitykees: 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
infinityslangasek: It is.17:24
keeshttps://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves <- updated17:24
keesokay, so this leaves us with only "should we do something more dramatic besides dropping from devel?"17:25
infinitykees: 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:25
ScottKExcept that we (via an updated package) just messed with the system that had it installed.  We owe an explanation.17:26
keesScottK: right, that happens on stable, but not devel.17:26
keeson devel, it's just gone.17:26
kees(uninstallable)17:26
infinityslangasek: 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:26
slangasekinfinity: if the package was previously removed manually, it could show the removal reason?17:27
infinityslangasek: 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
slangasekinfinity: um17:27
slangasekinfinity: if you remove a package, you have to give a removal reason :)17:27
infinityslangasek: But then, sure, we could show the -m17:28
slangasekright17:28
infinityslangasek: No, I was responding to your "the package was previously removed manually", that's not something we know. :)17:28
slangasekwell, ok17:28
slangasekbut we can filter out the autogenerated -m17:28
slangasekat least theoretically :)17:28
slangasekanyway17:28
slangasekI don't think that needs to block the plan overall17:29
slangasekshould we just take an action to follow up on that?17:29
infinityslangasek: Want to file a bug at lp.net/launchpad requesting such a feature?17:29
keeswhat action can be taken then?17:29
infinitykees: I think we should probably vote on the current wording and if we include it in the larger SRU doc.17:29
kees[action] slangasek to file a bug against LP to request showing manual package removal reason17:30
meetingologyACTION: slangasek to file a bug against LP to request showing manual package removal reason17:30
infinitykees: Oh, might be worth noting that removal history should be documented in the list given at the bottom of that page. :P17:30
slangasekbug #139626617:32
kees[vote] Approve wording on SRU Removals: https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves17:32
meetingologyPlease vote on: Approve wording on SRU Removals: https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves17:32
meetingologyPublic 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+117:32
meetingology+1 received from kees17:32
stgraber+117:32
meetingology+1 received from stgraber17:32
slangasek+117:32
meetingology+1 received from slangasek17:32
infinitykees: 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+117:32
meetingology+1 received from mdeslaur17:32
infinity+117:32
meetingology+1 received from infinity17:32
slangasekfwiw on reflection we don't need to distinguish between auto and manual removals... source packages are never truly autoremoved from LP AFAIK17:32
kees[endvote]17:32
meetingologyVoting ended on: Approve wording on SRU Removals: https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves17:32
meetingologyVotes for:5 Votes against:0 Abstentions:017:32
meetingologyMotion carried17:32
keesslangasek: okay, cool. and since the bug has been opened, I'll drop the action. :)17:33
infinityThe 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
slangasekwhat ever happened to the bitcoin request?17:33
keesinfinity: 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
slangasekdid that not use this process?17:33
infinitykees: 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
slangasekhttps://launchpad.net/ubuntu/+source/bitcoin/0.3.24~dfsg-1ubuntu0.2 it sure did17:34
infinityWell, look at that.  Three times!17:34
mdeslauroh, huh17:35
infinityAnd that has neither NEWS nor a debconf note. :/17:35
infinitySo just a silent neutering.17:35
slangasekheh17:36
keesinfinity: 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
infinitykees: That works for me.17:36
keesany object to that change, post-vote? :)17:36
keesI've added bitcoin to the list now too17:36
slangasekno objection17:36
mdeslaurno objection from me17:36
slangasekinfinity: there is too a debian/NEWS17:37
infinityI 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:37
kees[topic] mailing list archive17:38
infinityslangasek: Oh, so there is.  It was the same content as changelog, so I skipped right past it in the diff.17:38
keesthe only thing I see unaddressed here is Docker, but that seems to be continuing on the list.17:38
keesI 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
infinityThe docker thing might deserve some real-time discussion.17:39
keesI wanted functional testing for stable update regressions, pat said she'd check on upstream, but nothing new yet.17:40
infinityNot 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. :P17:40
infinityI 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:40
infinityAnd now the goalposts have shifted.17:41
keesWell, I have my own not entirely helpful solution for that case: upgrade Ubuntu every 6 months. :P17:41
infinityI 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:41
infinityExcept for the HWE stack, which I fear set an unfortunate pseudo-precedent in a lot of people's minds.17:42
keesthese kinds of things have always been Cloudy packages...17:42
ScottKOf course sabdfling has to be explicit and direct.17:42
mdeslaurwhat happens with security issues? ie: docker pre-1.3.2 right now allow host privilege escalation...17:42
slangasekmdeslaur: we trigger the SRU removal process? ;)17:42
mdeslaurhehehe17:42
infinitymdeslaur: Are there upstream fixes for that?  I was also assured that 1.0.x was an upstream supported release for a good while. :P17:42
kees+117:42
mdeslaurinfinity: yes, "upgrade to 1.3.2"17:43
infinitymdeslaur: Ugh.17:43
infinityAlso, ugh.17:43
keesthe sign of a mature and trusted upstream.17:43
slangasekdocker 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
infinitykees: I assume the irony of that comment in light of who signs your paycheque isn't lost on you. :)17:43
slangasekhmm17:44
keesinfinity: I live in a sea of irony.17:44
mdeslaurheh17:44
slangasekso if 1.0.x is not actually upstream-supported, I think it's important to revisit the assumptions of the original exception17:44
infinityRight.17:44
slangasekbefore we go granting further exceptions17:44
slangasekmdeslaur: sounds like you're in a position to drive that since you have the facts at your disposal?17:45
keesso, 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
mdeslaurslangasek: yes, let me investigate a bit more to get my facts straight and I'll respond to the thread17:45
keesas such, I think it's the responsibility of the requestor to produce such tests if they want the new versions.17:45
mdeslaurkees: add an action item for me, please17:45
infinitySo, 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:45
kees[action] mdeslaur to gather facts on docker versions and respond to the thread17:46
meetingologyACTION: mdeslaur to gather facts on docker versions and respond to the thread17:46
infinityAnd two, the "ship multiple upstream versions, whee" thing that seems to be becoming the server team's favourite workaround.17:46
slangasekkees: I believe we know that new upstream versions of docker are proven *to* break people if you try to just do an in-place upgrade17:46
infinityslangasek: Oh, how very fun.17:46
slangasekthat's why the proposal is to have them available under separate package names17:46
keesslangasek: oh great. then yeah, shipping docker1.3 becomes the "solution"?17:46
slangasekseems so17:47
infinityslangasek: But the multiple packages option helps no one if the older ones are unsupported and insecure.17:47
slangasekOTOH I don't have a source for the above claim, so maybe I'm just reading too much between the lines17:47
keeswell, that's ugly, but I can't say I'm opposed to it.17:47
slangasekinfinity: correct17:47
slangasekclearly the right solution is an app store on the server17:47
keesright, there's that part. *hold face*17:47
infinityslangasek: Because an app store would magically migrate users in a way that a package upgrade can't? :P17:48
keesinfinity: I think that was a sarcastic suggestion :)17:48
infinitykees: I read it as sarcasm, but chose to respond straight.17:48
slangasekinfinity: an app store would get us out of the position of having to adjudicate the relationship between the upstream and the user :)17:48
keesactual LOL17:48
slangasekno, it wasn't sarcastic17:48
infinityAnd yes, that's why.17:48
infinityIt means it's upstream's fault when they break upgrades, not ours.17:48
infinityIn theory.17:48
keesokay, clearly we should take this to the ML, which mdeslaur has an action for already.17:49
slangasekif docker weren't in Ubuntu, we wouldn't have to try to make it fit Ubuntu policies17:49
infinityI don't believe that theory holds true in practice on a platform like ours.17:49
infinityBut I could be wrong.17:49
kees[topic] AOB17:49
keesany surprise topics?17:49
infinityI'm pregnant!17:49
keesIT'S NOT MINE17:50
infinityAre you sure?17:50
mdeslaurheh17:50
kees[topic] next chair17:50
keeslooks like mdeslaur ?17:50
mdeslaurfine by me!17:50
infinityYep.17:50
keesboooom, done.17:50
keesthanks everyone!17:51
* infinity waves.17:51
kees#endmeeting17:51
meetingologyMeeting ended Tue Nov 25 17:51:28 2014 UTC.17:51
meetingologyMinutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2014/ubuntu-meeting-2.2014-11-25-17.03.moin.txt17:51
stgraberthanks!17:51
slangasekthanks, all!17:51
mdeslaurthanks everyone!17:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!