14:01:27 #startmeeting 14:01:27 Meeting started Mon Dec 17 14:01:27 2012 UTC. The chair is barry. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 14:01:27 14:01:27 Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired 14:01:50 hello and welcome to the last ubuntu developer membership board meeting of 2012 14:02:01 hi 14:02:43 the last DMB meeting before the world will end :D 14:02:46 do we have quorum today? 14:02:51 o/ 14:02:58 barry: yes 14:03:21 bdrung: if we give ~mayans upload rights will that avoid doomsday? 14:03:28 hey 14:03:56 #topic Review of previous action items 14:04:07 micahg to document the zentyal packageset 14:04:09 barry: they should do uploads directly to Debian and wait for their next stable release. ;) 14:04:14 nope, will do over vacation 14:04:19 micahg: thanks 14:04:26 micahg to ask docs people if they want to apply for a packageset 14:04:30 same? 14:04:39 let's drop this, I don't remember why this is necessary ATM 14:04:49 k 14:04:55 I believe the relevant people have upload rights already 14:05:11 #topic Review any packageset descriptions that have been received (micahg) 14:05:15 oh, wait, now I remember 14:05:39 leave it on, I'll try to ping the relevant person over vacation 14:05:47 micahg: ok 14:05:49 and try to finish the packageset descriptions as well 14:05:56 cool, thanks 14:06:14 #topic Lightweight process for amending PPU rights (for DDs?) (Laney) 14:06:31 yeah so 14:06:44 sometimes we grant DDs PPU for "their packages" 14:06:59 but we don't really have a way of extending this when they acquire more over time 14:07:16 I suppose we should? 14:07:40 having one or two people ack it on the mailing list would work for me 14:07:54 in general we usually say that it's a good idea to make the path for DDs wanting to upload to Ubuntu as smooth as possible 14:08:09 tumbleweed: +1 14:08:19 yeah, this should be fine as long as they're not migrating from not on ISO -> ISO or no rdeps to lots of rdeps 14:08:22 people on the dmb? 14:08:36 and specifically for DDs 14:08:54 one ACK on the mailing list without any dmb member against it 14:08:59 apparently this came up before, let me find the irc log 14:09:26 2010-11-02 14:09:40 then we expect that DMB member to do some research (e.g. determine if it's the uploader's first seeded package) 14:09:51 http://irclogs.ubuntu.com/2010/11/02/%23ubuntu-meeting.html#t15:04 14:09:52 could we extent the PPU right application to apply for package groups like we do for package sets (i apply for foo-* / i apply for my DD packages) 14:10:02 yes, that happens 14:11:09 I wouldn't say that we need to ask the TB to ack this, despite the fact that it was the TB who had ^^^ discussion 14:11:30 right, these are folks who already have dd and some ubuntu upload rights, so i think a lightweight verification of ongoing good work should be sufficient 14:11:46 so it's 14:11:48 - be a DD 14:12:04 - have attended the DMB before and gotten some PPU 14:12:17 - not be extending the 'impact' of the packages (or you get further questioning by email) 14:12:44 sounds good 14:13:19 and specifically asking for ppu on packages they are the debian maintainer of? 14:13:33 or in the team which is 14:13:39 maybe? 14:14:09 yeah, i was going to ask about teams :) 14:14:20 Laney: then they should be uploaders of these packages 14:14:30 if they've been an active recent uploader of it, then team member would be ok for me 14:14:42 yeah, if it's team maintained and they are DD, they are probably expected to upload, so that seems fine (assuming the other conditions are met) 14:14:42 but they should probably be an Uploader at that point... 14:14:54 not all teams manage uploaders in the same way 14:15:07 some teams are quite big 14:15:14 fair enough 14:15:14 if they're active on the package (use judgement) then it should be ok 14:15:18 look at uploads or vcs or whatever 14:15:20 re number of packages 14:15:36 at some point, for a biggish team, I'd image that packagesets start making more sense than PPU 14:15:55 maybe we can just say that if laney's three criteria are met, expedited ppu *can* be provided, but still at the discretion of the dmb. then we can more or less take it case-by-case 14:16:00 perhaps 14:16:05 action me to wikify it and mail 14:16:11 the packages overview for Debian Multimedia Maintainers shows 369 packages, for example 14:16:40 #action laney to describe criteria and process for lightweight amending of ppu rights (for dds) 14:16:40 * meetingology laney to describe criteria and process for lightweight amending of ppu rights (for dds) 14:17:05 shall we move on? 14:17:21 #topic Package Sets 14:17:26 none today 14:17:34 #topic PerPackageUploader Applications 14:17:50 roadmr: hi, are you here today? 14:17:54 hello! 14:18:05 #link https://wiki.ubuntu.com/DanielManrique/PerPackageUploadRightsApplication 14:18:18 roadmr: could you introduce yourself and describe what you're applying for? 14:18:28 Sure! 14:18:33 Hi, I'm Daniel. I'm a hardware certification engineer at Canonical. 14:18:38 I'm part of the team responsible for the checkbox system testing tool that ships with Ubuntu, and I usually handle preparation of the checkbox code that will go up into Ubuntu. 14:18:52 We rely on help from sponsors to get our changes up into Ubuntu. I'd like to be able to contribute in a more effective way by handling these uploads myself. 14:19:00 This will let me take some workload off our sponsors, work more closely with other checkbox contributors, and gaining more experience in the upload process to hopefully help sponsors with upload reviewing. 14:19:13 Thanks! 14:19:59 .. 14:20:34 roadmr: is checkbox Ubuntu specific? 14:20:46 bdrung: yes, it doesn't exist in Debian 14:21:20 * Laney is re-reading the application 14:21:38 bdrung: It *could* potentially be made to work on Debian, it's just work we haven't done 14:21:55 roadmr: let me rephrase my question. can checkbox only be used in Ubuntu or could it be used by other distributions for QA, too? 14:22:32 bdrung: oh I understand now. It could be used by other distros, some work would be required 14:22:49 bdrung: on the packaging front it may depend on packages and/or versions that may only make sense in Ubuntu 14:23:14 roadmr: then it would be nice if checkbox would be change to a non-native format. 14:23:23 bdrung: and some of the tests depend on packages and/or services that are default in Ubuntu but may be optional in other distros, so are not declared as explicit dependencies, without those the tests will fail 14:23:53 roadmr: is there a way to make tests optional or easily disabled? 14:24:20 roadmr: depending on what they are, perhaps they should be part of the build dependencies then 14:24:26 bdrung: we have plans for that, so that checkbox can be distributed as a source tar.gz and Ubuntu packaging be added afterwards, this would ease use by other distros - again, it's in the list of things we want to do but nothing concrete yet 14:24:40 i see the tendency to make package native just because it should be put in Ubuntu (despite the fact that the package could be useful on other distributions) 14:25:04 barry: yes, you can either declare which tests to run in a "runlist" (we call them whitelists), or simply remove the check mark for each test in a selection screen 14:26:26 micahg: yes, part of the work to ensure it runs well in other distros would be having a good look at dependencies and maybe declaring them explicitly per-test (checkbox supports this, but we obviate when we know it's included by default in Ubuntu) 14:27:17 roadmr: so, historically, checkbox has had some difficulty around the ubuntu release cycle 14:27:19 roadmr: right, but even in Ubuntu, you still need to declare dependencies that aren't in essential/transitive essential/build essentia; 14:27:32 what is the checkbox release cycle? 14:27:36 in case it's no longer "defulat" 14:27:38 *default 14:28:45 micahg: yes, we've been trying to be more diligent with that, we try to add essential dependencies (such as udisks) 14:29:34 tumbleweed: we don't have a formal release cycle as such, we try to adhere to the Ubuntu release schedule as far as making big changes early in the cycle 14:30:03 tumbleweed: one of our plans for this cycle was to come up with a decent development/release/versioning plan for checkbox 14:30:13 so, there isn't really any reason that checkbox should have trouble with the ubuntu release cycle 14:31:01 I seem to recall a fair number of checkbox releases post FF 14:31:09 tumbleweed: you're right. What's happened historically is that we sometimes have new features that land in our development branch a bit late in the cycle 14:31:28 tumbleweed: so as you noted we have to resort to requesting FFes for those features to make it into the release 14:31:44 right, and I think you got almost all of them 14:31:56 but it can be a slow process... 14:32:05 tumbleweed: this is something we need to improve, we need a bit of discipline in trying to get all the changes *before* FF 14:32:26 tumbleweed: but also within the team, being more strict so that we don't dump the need to say "no" on to the release team 14:32:55 tumbleweed: yes, in that respect we've had a lot of support from the release team but as I said, it'd be fairer to everyone if we strive to not do those disruptive changes after FF 14:33:04 now FF has been pushed back, so the chance of the release team saying no is probably higher 14:33:25 tumbleweed: yes, OTOH we have more time to get those big changes in place :) 14:33:39 with more opportunity to get the needed changes in before then 14:33:49 :) 14:34:14 There are a few comments on the application wiki about sponsors being the ones who spot the need for exceptions. If you're granted PPU then there will be no sponsor firewal. Are you confident this won't be a problem? 14:35:37 Laney: I'm a bit scared about not having the extra safety net of an sponsor, but I think that will just encourage me to be extra anal when it comes to deciding whether an exception is needed 14:35:51 Nobody likes getting a micahg nastygram on -devel :P 14:36:06 lol 14:36:11 :) 14:36:24 Laney: that scares the living daylights out of me, so yes, if in any doubt I'd ask first :) but if in doubt, I'd just go ahead and go through the exception process 14:37:04 roadmr: how do you know if an exception is necessary? what resources would you consult? 14:37:47 barry: I usually read and reread https://wiki.ubuntu.com/FreezeExceptionProcess and look at the release schedule to see where we are 14:38:22 barry: I've also learned to "interpret" this a bit, for instance, we did some UI-related changes which needed some code changes to back them 14:38:53 barry: my initial intuition was that this was UIFe, since the code changes were minor, but the sponsor still felt it also needed FFe, so I ended up requesting both 14:39:33 barry: so lesson learned, which I'll keep in mind in the future - doing both exceptions from the get-go would have saved us a few days on that one 14:39:46 roadmr: for example: https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.8/+merge/127923 14:40:44 roadmr: was there a ffe bug on that one? apulido's comment indicates an ffe was granted but no record of that was given 14:41:18 it was granted by laney in the bug 14:41:35 barry: usually code that closes bugs should not need FFe, but this was an instance where the closed bug was actually implementing a (small) feature 14:41:49 barry: yes, the bug was the one with the FFe (https://bugs.launchpad.net/checkbox/+bug/1060211) 14:41:51 Ubuntu bug 1060211 in checkbox "[FFe] graphics_driver script does not report proprietary driver version" [Low,Fix released] 14:41:56 ah,cool, thanks 14:42:45 barry: that's how we usually do it, exceptions are requested on bugs, then the merge request and candidate bug should mention those. 14:43:07 roadmr: fixing a bug can mean fixing a crash/defect or adding a new feature (wishlist bugs) 14:43:36 roadmr: rewriting a big portion of code to fix a bug can require a FFe too 14:44:28 bdrung: yes, well this is an area where some discretion/judgment is needed I guess, as to how much code qualifies as "just a bug fix" as opposed to "fixing a bug by adding a new feature" 14:45:24 roadmr: yes, that can be a dicey question sometimes 14:45:38 bdrung: we wouldn't try to get wishlist bugs in without FFe, this bug we mentioned wasn't wishlist and the phrasing suggested just a hardware detection failure but, on a closer look, it did constitute a new feature 14:46:53 roadmr: I'm sure you're also aware that with checkbox being on multiple ISOs and trying to keep everything daily installable, that breakage will need to be dealt with swiftly? 14:48:03 micahg: yes, we have quite a few people who are able to work on checkbox now, so we should be able to respond to breakage more quickly 14:48:57 micahg: we usually notice checkbox failures during our periodic (usually at least weekly) testing 14:49:04 #vote grant roadmr ppu rights to checkbox 14:49:04 Please vote on: grant roadmr ppu rights to checkbox 14:49:04 Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) 14:49:07 #voters bdrung, cody-somerville, Laney, micahg, barry, tumbleweed, stgraber 14:49:07 Warning: Nick not in channel: cody-somerville 14:49:07 Current voters: Laney barry bdrung cody-somerville micahg stgraber tumbleweed 14:49:23 +1 14:49:23 +1 received from barry 14:49:27 roadmr: right, but as the uploader, you're taking responsibility for driving and getting that fix in 14:49:42 +1 14:49:42 +1 received from bdrung 14:49:45 +1 14:49:45 +1 received from tumbleweed 14:49:55 +1 14:49:55 +1 received from Laney 14:50:04 +1 14:50:04 +1 received from micahg 14:50:31 micahg: right, well if I'm able to do the uploads myself it actually eases things because I don't have to pester sponsors for help with the upload :) 14:50:48 +1 14:50:48 +1 received from stgraber 14:51:33 #endvote 14:51:33 Voting ended on: grant roadmr ppu rights to checkbox 14:51:33 Votes for:6 Votes against:0 Abstentions:0 14:51:33 Motion carried 14:51:36 congrats! 14:51:42 congrats roadmr! 14:51:47 \o/ awesome, thanks folks! 14:52:09 and thanks for the thorough interview, lots of food for thought and material to review 14:52:26 #topic Ubuntu Contributing Developer Applications 14:52:28 none today 14:52:37 roadmr: congrats :) 14:52:39 #topic MOTU Applications 14:52:41 none today 14:52:50 #topic Ubuntu Core Developer Applications 14:52:54 none today 14:53:01 #topic next meeting 14:53:17 january 7th 2013, 1900 utc 14:53:37 bdrung: you're up next for chair 14:53:44 barry: i was already 14:53:57 (we skipped you, because you weren't there) 14:54:02 oops :) 14:54:23 i guess that's why i did 2 in a row for penance :) 14:54:25 cody then, with backup from Laney 14:54:40 #topic aob 14:55:00 any other business for today? 14:55:19 haven't seen cody around much lately 14:55:22 is he still active? 14:55:48 that's a good question. i can send him an email 14:56:19 probably worth a gentle poke 14:56:24 #action barry to ping cody 14:56:24 * meetingology barry to ping cody 14:57:05 so, I guess NYE isn't going to happen :-) 14:57:29 on that note... 14:57:30 ah, jan 7th 14:57:39 #endmeeting