| kees | \o | 16:59 |
|---|---|---|
| * stgraber waves | 16:59 | |
| mdeslaur | \o | 17:00 |
| kees | slangasek: ready? | 17:01 |
| infinity | I'm sort of here, and sort of recovering from vacation (done) and a flu (ongoing), so don't expect intelligent debate. :P | 17:02 |
| kees | heh :) | 17:02 |
| 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 | 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:03 |
| 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:04 |
| 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:05 |
| slangasek | that's where the test plan needs to be recorded | 17:06 |
| mdeslaur | where is the test for kubuntu? | 17:06 |
| kees | Riddell: thoughts? | 17:08 |
| Riddell | I've updated bug 1378789 now | 17:08 |
| Riddell | with test case for kubuntu and unity | 17:08 |
| slangasek | ok, looks good to me | 17:09 |
| kees | great, thanks! | 17:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| slangasek | if we're having packages removed/added/removed, it sounds to me like the current mechanism isn't sufficient | 17:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 | |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| kees | [action] slangasek to file a bug against LP to request showing manual package removal reason | 17:30 |
| meetingology | ACTION: 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:30 |
| 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:32 |
| 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:33 |
| 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:34 |
| mdeslaur | oh, huh | 17:35 |
| infinity | And that has neither NEWS nor a debconf note. :/ | 17:35 |
| infinity | So just a silent neutering. | 17:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| kees | [action] mdeslaur to gather facts on docker versions and respond to the thread | 17:46 |
| meetingology | ACTION: 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| kees | thanks everyone! | 17:51 |
| * infinity waves. | 17:51 | |
| kees | #endmeeting | 17:51 |
| meetingology | Meeting ended Tue Nov 25 17:51:28 2014 UTC. | 17:51 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2014/ubuntu-meeting-2.2014-11-25-17.03.moin.txt | 17:51 |
| stgraber | thanks! | 17:51 |
| slangasek | thanks, all! | 17:51 |
| mdeslaur | thanks everyone! | 17:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!