#ubuntu-meeting log

14:01:27 <barry> #startmeeting
14:01:27 <meetingology> 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 <meetingology> 
14:01:27 <meetingology> 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 <barry> hello and welcome to the last ubuntu developer membership board meeting of 2012
14:02:01 <tumbleweed> hi
14:02:43 <bdrung> the last DMB meeting before the world will end :D
14:02:46 <barry> do we have quorum today?
14:02:51 <micahg> o/
14:02:58 <bdrung> barry: yes
14:03:21 <barry> bdrung: if we give ~mayans upload rights will that avoid doomsday?
14:03:28 <Laney> hey
14:03:56 <barry> #topic Review of previous action items
14:04:07 <barry> micahg to document the zentyal packageset
14:04:09 <bdrung> barry: they should do uploads directly to Debian and wait for their next stable release. ;)
14:04:14 <micahg> nope, will do over vacation
14:04:19 <barry> micahg: thanks
14:04:26 <barry> micahg to ask docs people if they want to apply for a packageset
14:04:30 <barry> same?
14:04:39 <micahg> let's drop this, I don't remember why this is necessary ATM
14:04:49 <barry> k
14:04:55 <micahg> I believe the relevant people have upload rights already
14:05:11 <barry> #topic Review any packageset descriptions that have been received (micahg)
14:05:15 <micahg> oh, wait, now I remember
14:05:39 <micahg> leave it on, I'll try to ping the relevant person over vacation
14:05:47 <barry> micahg: ok
14:05:49 <micahg> and try to finish the packageset descriptions as well
14:05:56 <barry> cool, thanks
14:06:14 <barry> #topic Lightweight process for amending PPU rights (for DDs?) (Laney)
14:06:31 <Laney> yeah so
14:06:44 <Laney> sometimes we grant DDs PPU for "their packages"
14:06:59 <Laney> but we don't really have a way of extending this when they acquire more over time
14:07:16 <Laney> I suppose we should?
14:07:40 <tumbleweed> having one or two people ack it on the mailing list would work for me
14:07:54 <Laney> 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 <barry> tumbleweed: +1
14:08:19 <micahg> 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 <Laney> people on the dmb?
14:08:36 <micahg> and specifically for DDs
14:08:54 <bdrung> one ACK on the mailing list without any dmb member against it
14:08:59 <Laney> apparently this came up before, let me find the irc log
14:09:26 <Laney> 2010-11-02
14:09:40 <tumbleweed> 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 <Laney> http://irclogs.ubuntu.com/2010/11/02/%23ubuntu-meeting.html#t15:04
14:09:52 <bdrung> 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 <Laney> yes, that happens
14:11:09 <Laney> 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 <barry> 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 <Laney> so it's
14:11:48 <Laney> - be a DD
14:12:04 <Laney> - have attended the DMB before and gotten some PPU
14:12:17 <Laney> - not be extending the 'impact' of the packages (or you get further questioning by email)
14:12:44 <tumbleweed> sounds good
14:13:19 <barry> and specifically asking for ppu on packages they are the debian maintainer of?
14:13:33 <Laney> or in the team which is
14:13:39 <Laney> maybe?
14:14:09 <barry> yeah, i was going to ask about teams :)
14:14:20 <bdrung> Laney: then they should be uploaders of these packages
14:14:30 <tumbleweed> if they've been an active recent uploader of it, then team member would be ok for me
14:14:42 <micahg> 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 <tumbleweed> but they should probably be an Uploader at that point...
14:14:54 <Laney> not all teams manage uploaders in the same way
14:15:07 <bdrung> some teams are quite big
14:15:14 <tumbleweed> fair enough
14:15:14 <Laney> if they're active on the package (use judgement) then it should be ok
14:15:18 <Laney> look at uploads or vcs or whatever
14:15:20 <bdrung> re number of packages
14:15:36 <tumbleweed> at some point, for a biggish team, I'd image that packagesets start making more sense than PPU
14:15:55 <barry> 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 <Laney> perhaps
14:16:05 <Laney> action me to wikify it and mail
14:16:11 <bdrung> the packages overview for Debian Multimedia Maintainers shows 369 packages, for example
14:16:40 <barry> #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 <barry> shall we move on?
14:17:21 <barry> #topic Package Sets
14:17:26 <barry> none today
14:17:34 <barry> #topic PerPackageUploader Applications
14:17:50 <barry> roadmr: hi, are you here today?
14:17:54 <roadmr> hello!
14:18:05 <barry> #link https://wiki.ubuntu.com/DanielManrique/PerPackageUploadRightsApplication
14:18:18 <barry> roadmr: could you introduce yourself and describe what you're applying for?
14:18:28 <roadmr> Sure!
14:18:33 <roadmr> Hi, I'm Daniel. I'm a hardware certification engineer at Canonical.
14:18:38 <roadmr> 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 <roadmr> 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 <roadmr> 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 <roadmr> Thanks!
14:19:59 <roadmr> ..
14:20:34 <bdrung> roadmr: is checkbox Ubuntu specific?
14:20:46 <roadmr> bdrung: yes, it doesn't exist in Debian
14:21:20 * Laney is re-reading the application
14:21:38 <roadmr> bdrung: It *could* potentially be made to work on Debian, it's just work we haven't done
14:21:55 <bdrung> 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 <roadmr> bdrung: oh I understand now. It could be used by other distros, some work would be required
14:22:49 <roadmr> bdrung: on the packaging front it may depend on packages and/or versions that may only make sense in Ubuntu
14:23:14 <bdrung> roadmr: then it would be nice if checkbox would be change to a non-native format.
14:23:23 <roadmr> 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 <barry> roadmr: is there a way to make tests optional or easily disabled?
14:24:20 <micahg> roadmr: depending on what they are, perhaps they should be part of the build dependencies then
14:24:26 <roadmr> 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 <bdrung> 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 <roadmr> 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 <roadmr> 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 <tumbleweed> roadmr: so, historically, checkbox has had some difficulty around the ubuntu release cycle
14:27:19 <micahg> roadmr: right, but even in Ubuntu, you still need to declare dependencies that aren't in essential/transitive essential/build essentia;
14:27:32 <tumbleweed> what is the checkbox release cycle?
14:27:36 <micahg> in case it's no longer "defulat"
14:27:38 <micahg> *default
14:28:45 <roadmr> micahg: yes, we've been trying to be more diligent with that, we try to add essential dependencies (such as udisks)
14:29:34 <roadmr> 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 <roadmr> tumbleweed: one of our plans for this cycle was to come up with a decent development/release/versioning plan for checkbox
14:30:13 <tumbleweed> so, there isn't really any reason that checkbox should have trouble with the ubuntu release cycle
14:31:01 <tumbleweed> I seem to recall a fair number of checkbox releases post FF
14:31:09 <roadmr> 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 <roadmr> tumbleweed: so as you noted we have to resort to requesting FFes for those features to make it into the release
14:31:44 <tumbleweed> right, and I think you got almost all of them
14:31:56 <tumbleweed> but it can be a slow process...
14:32:05 <roadmr> 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 <roadmr> 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 <roadmr> 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 <tumbleweed> now FF has been pushed back, so the chance of the release team saying no is probably higher
14:33:25 <roadmr> tumbleweed: yes, OTOH we have more time to get those big changes in place :)
14:33:39 <barry> with more opportunity to get the needed changes in before then <wink>
14:33:49 <tumbleweed> :)
14:34:14 <Laney> 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 <roadmr> 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 <Laney> Nobody likes getting a micahg nastygram on -devel :P
14:36:06 <micahg> lol
14:36:11 <barry> :)
14:36:24 <roadmr> 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 <barry> roadmr: how do you know if an exception is necessary?  what resources would you consult?
14:37:47 <roadmr> 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 <roadmr> 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 <roadmr> 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 <roadmr> 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 <barry> roadmr: for example: https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.8/+merge/127923
14:40:44 <barry> 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 <micahg> it was granted by laney in the bug
14:41:35 <roadmr> 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 <roadmr> barry: yes, the bug was the one with the FFe (https://bugs.launchpad.net/checkbox/+bug/1060211)
14:41:51 <ubottu> Ubuntu bug 1060211 in checkbox "[FFe] graphics_driver script does not report proprietary driver version" [Low,Fix released]
14:41:56 <barry> ah,cool, thanks
14:42:45 <roadmr> 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 <bdrung> roadmr: fixing a bug can mean fixing a crash/defect or adding a new feature (wishlist bugs)
14:43:36 <bdrung> roadmr: rewriting a big portion of code to fix a bug can require a FFe too
14:44:28 <roadmr> 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 <barry> roadmr: yes, that can be a dicey question sometimes
14:45:38 <roadmr> 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 <micahg> 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 <roadmr> 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 <roadmr> micahg: we usually notice checkbox failures during our periodic (usually at least weekly) testing
14:49:04 <barry> #vote grant roadmr ppu rights to checkbox
14:49:04 <meetingology> Please vote on: grant roadmr ppu rights to checkbox
14:49:04 <meetingology> 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 <barry> #voters bdrung, cody-somerville, Laney, micahg, barry, tumbleweed, stgraber
14:49:07 <meetingology> Warning: Nick not in channel: cody-somerville
14:49:07 <meetingology> Current voters: Laney barry bdrung cody-somerville micahg stgraber tumbleweed
14:49:23 <barry> +1
14:49:23 <meetingology> +1 received from barry
14:49:27 <micahg> roadmr: right, but as the uploader, you're taking responsibility for driving and getting that fix in
14:49:42 <bdrung> +1
14:49:42 <meetingology> +1 received from bdrung
14:49:45 <tumbleweed> +1
14:49:45 <meetingology> +1 received from tumbleweed
14:49:55 <Laney> +1
14:49:55 <meetingology> +1 received from Laney
14:50:04 <micahg> +1
14:50:04 <meetingology> +1 received from micahg
14:50:31 <roadmr> 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 <stgraber> +1
14:50:48 <meetingology> +1 received from stgraber
14:51:33 <barry> #endvote
14:51:33 <meetingology> Voting ended on: grant roadmr ppu rights to checkbox
14:51:33 <meetingology> Votes for:6 Votes against:0 Abstentions:0
14:51:33 <meetingology> Motion carried
14:51:36 <Laney> congrats!
14:51:42 <barry> congrats roadmr!
14:51:47 <roadmr> \o/ awesome, thanks folks!
14:52:09 <roadmr> and thanks for the thorough interview, lots of food for thought and material to review
14:52:26 <barry> #topic Ubuntu Contributing Developer Applications
14:52:28 <barry> none today
14:52:37 <bdrung> roadmr: congrats :)
14:52:39 <barry> #topic MOTU Applications
14:52:41 <barry> none today
14:52:50 <barry> #topic Ubuntu Core Developer Applications
14:52:54 <barry> none today
14:53:01 <barry> #topic next meeting
14:53:17 <barry> january 7th 2013, 1900 utc
14:53:37 <barry> bdrung: you're up next for chair
14:53:44 <bdrung> barry: i was already
14:53:57 <bdrung> (we skipped you, because you weren't there)
14:54:02 <barry> oops :)
14:54:23 <barry> i guess that's why i did 2 in a row for penance :)
14:54:25 <barry> cody then, with backup from Laney
14:54:40 <barry> #topic aob
14:55:00 <barry> any other business for today?
14:55:19 <Laney> haven't seen cody around much lately
14:55:22 <Laney> is he still active?
14:55:48 <barry> that's a good question.  i can send him an email
14:56:19 <Laney> probably worth a gentle poke
14:56:24 <barry> #action barry to ping cody
14:56:24 * meetingology barry to ping cody
14:57:05 <Laney> so, I guess NYE isn't going to happen :-)
14:57:29 <barry> on that note...
14:57:30 <Laney> ah, jan 7th
14:57:39 <barry> #endmeeting