16:01:21 <ara> #startmeeting
16:01:21 <meetingology> Meeting started Mon Feb 20 16:01:21 2012 UTC.  The chair is ara. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
16:01:21 <meetingology> 
16:01:21 <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
16:01:33 <ara> welcome to the Ubuntu Friendly meeting #34
16:01:54 <ara> #topic Optical drive testing for Ubuntu Friendly (roadmr)
16:02:10 <roadmr> hi all!
16:02:49 <roadmr> The situation is as follows. We now have a very nice automated CD writing test
16:03:03 <roadmr> what it does is, it asks for blank media, writes some files to it, and then tries to read them
16:03:31 <roadmr> this enables us to test reading and writing with just one test, thus being quicker for the user
16:03:44 <roadmr> the problem is, the way the test was designed, it would be the *only* CD test run
16:03:59 <roadmr> and the consequence for Ubuntu Friendly is that, if the drive supports writing, this test will ask the user for blank media
16:04:09 <roadmr> if the user has no blank media, the test will either fail or be skipped
16:04:21 <ara> o/
16:04:33 <roadmr> and since CD functionality is considered core, we'll be giving the system one star (fail) if the user happened to not have (or not want to waste) a blank disk
16:04:58 <roadmr> So for the time being we're still using only the read test for CD, and this awesome CD writing test is not used at all :)
16:05:32 <roadmr> We'd like some feedback on how to handle this, one of the ideas being to change the "coreness" of the CD tests, making them optional/additional
16:06:00 <roadmr> another possibility would be to rework this test so it behaves differently
16:06:04 <brendand> o/
16:06:43 <roadmr> and yet another would be the vaunted feature where checkbox supports various exit statuses so the test can say why it didn't run and not be considered an outright failure.
16:06:55 <roadmr> So that's the situation. Ideas anyone?
16:07:06 <roadmr> ara, you're first
16:07:11 <ara> hey
16:07:32 <ara> so, basically, we have three (and not two) types of tests: optional, core and skippable core
16:07:45 <ara> I think we need to keep 2 tests
16:07:56 <ara> the read one to be core, and the write one to be skippable
16:08:15 <ara> to have only one for Ubuntu Friendly is not the answer
16:08:22 <ara> as many people would skip the write one
16:08:41 <ara> and in the end no one would be testing even the reading capabilities
16:08:43 <ara> ..
16:09:14 <roadmr> OK, yes, the original proposal was to skip the read-only test entirely if the write one was runnable
16:09:17 <roadmr> brendand: your turn
16:09:31 <brendand> similar to what ara said
16:09:53 <brendand> it's fairly straightforward,
16:10:11 <brendand> any test which has a valid reason why it could not be run should be skippable
16:11:04 <brendand> i don't see how the read one should be core though. if the tester doesn't have a disc to test with we should really give the system one star?
16:11:21 <ara> brendand, agree
16:11:31 <ara> brendand, I stand corrected, both should be skippable
16:12:08 <roadmr> jedimike, could you remind us how the optical tests are considered right now? are they core-core or core-skippable? :)
16:12:21 <brendand> i guess in theory the wireless test for example could also not be testable, but in that case the hardware is so important it shouldn't be skippable
16:12:40 <jedimike> roadmr: let me check...
16:12:47 <brendand> for optical media i think a penalty is enough
16:14:00 <brendand> a further conundrum is if the drive doesn't have a write capability then it will be penalised
16:14:19 <brendand> even though it could never be expected to support that capability
16:14:56 <brendand> how to deal with that?
16:14:57 <brendand> ...
16:15:21 <jedimike> optical is core, in the 11.10 tests dvd-write, cdrom-write, read_sr1 and read_sr0 are core-skippable. In 12.04 they're core-core. Do we want the mappings and skipping lists copied over to the 12.04 config now?
16:16:22 <roadmr> jedimike: for 12.04 the whitelist shows only optical/detect and optical/read, there are no more write tests (at least not on the whitelist)
16:16:48 <jedimike> roadmr: ok, the category mappings still need to be copied across though, I'll get on to that.
16:17:07 <ara> roadmr, jedimike: I think we need an action item to coordinate and fix the mappings for 12.04
16:17:52 <jedimike> ara: ok. I'll get the category mappings done now, it won't take me more than a few minutes. Then we can do the skippable stuff later. Once we go to production, there'll need to be an action item to get the mappings copied from staging.
16:18:35 <roadmr> ara: also the whitelist could potentially still change, so I'd say not to set the mappings "in stone" until later
16:19:09 <ara> agree, but we need to start selecting the skippable
16:19:17 <ara> to start gathering data on staging
16:19:22 <ara> and be able to fix stuff
16:19:23 <ara> ..
16:19:35 <roadmr> ara: we can put the write test back, but keep the read one, it's a bit of duplication but it's the best way to collect all that data
16:20:00 <roadmr> ara: agreed, so the most pressing thing would be to look at the current whitelist and see how the tests are classified
16:20:35 <roadmr> anyone want to work with jedimike on this? :)
16:20:40 <roadmr> (I can do it)
16:21:41 <roadmr> [ACTION] jedimike and roadmr to review the current default checkbox whitelist to ensure core-core/core-skippable/skippable-skippable mappings still make sense
16:21:41 * meetingology jedimike and roadmr to review the current default checkbox whitelist to ensure core-core/core-skippable/skippable-skippable mappings still make sense
16:22:48 <roadmr> [ACTION] bladernr, roadmr and spineau to decide whether it makes sense to put the optical/write test back without removing the read one, so that functionality gets at least tested (will penalize if the user decides to skip)
16:22:48 * meetingology bladernr, roadmr and spineau to decide whether it makes sense to put the optical/write test back without removing the read one, so that functionality gets at least tested (will penalize if the user decides to skip)
16:22:57 <roadmr> anything else needed on this topic?
16:24:04 <ara> OK, let's move on!
16:24:08 <ara> #topic "The Eagle has landed" - Checkbox-qt now available in Precise, call for testing (roadmr)
16:24:15 <ara> roadmr, all yours (again)
16:24:23 <roadmr> heheh :) I blame bladernr
16:24:43 <roadmr> anyway - so yes, the new and shiny checkbox-qt interface for Checkbox has landed in Ubuntu.
16:24:58 <cr3> o/
16:25:15 <roadmr> As usual we'd appreciate help from everyone testing it and filing bugs so we can fix them and ensure the new UI is as usable as possible.
16:25:23 <roadmr> To use it, just apt-get install checkbox-qt
16:25:30 <roadmr> and run checkbox-qt instead of checkbox-gtk
16:26:01 <roadmr> So please test and either send your comments to the mailing list or file Launchpad bugs for the stuff that bugs you!
16:26:04 <roadmr> ..
16:26:09 <roadmr> cr3: go ahead!
16:26:14 <cr3> just to announce that we're still in the process of getting checkbox-qt on the desktop image but there's no significant blockers so far
16:26:17 <cr3> ..
16:26:37 <roadmr> cr3: awesome, thanks! yes, for now it requires manual installation but the package is tiny so the pain should be minimal
16:28:36 <roadmr> that's all really on this topic :)
16:28:50 <ara> OK, any other questions or comments on the topic?
16:29:17 <ara> #topic AOB
16:29:27 <ara> Anybody else has any other topics to talk about?
16:29:40 <ara> without the else, of course
16:29:50 <ara> if roadmr has other topics he's more than welcome to share them :)
16:29:57 * roadmr has nothing else :(
16:30:27 <ara> going once...
16:30:37 <ara> going twice...
16:30:42 <ara> #endmeeting