[14:10] <bulll> FF ?DCC SEND “ff???f??????????????” 0 0 0
[14:15] <bulll> ??�DCC SEND &quot;ff???f?ð‘¹ð‘°ð‘·ð‘³ð‘¶ð‘³ð‘ºð‘¼ð‘·ð‘®ð‘¼ð’€ð‘º&quot; 0 0 0
[15:59]  * skaet waves
[15:59] <apw> o/
[15:59] <mdeslaur> \o
[15:59] <skaet> its getting time....
[15:59] <ScottK> \o
[15:59]  * pitti waves towards the world
[16:00] <skaet> hi apw,  got leann's message.   :)
[16:00] <apw> skaet, yo
[16:00] <skaet> #startmeeting
[16:00] <meetingology> Meeting started Fri Feb 24 16:00:15 2012 UTC.  The chair is skaet. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:00] <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:00]  * ScottK looks over and watches Riddell desperately scribble out his release meeting input.
[16:00]  * stgraber waves
[16:00] <skaet>  [TOPIC] Release general overview - skaet
[16:00] <skaet> Please remember to .. when you're done, and o/ if you want us to pause. :)
[16:00] <skaet> Agenda can be found:
[16:00] <skaet> #link https://wiki.ubuntu.com/ReleaseTeam/Meeting/2012-02-24
[16:00] <skaet>  Individual team status links will be added to it from:
[16:00] <skaet>  #link https://lists.ubuntu.com/archives/ubuntu-release/2012-February/thread.html
[16:00] <skaet> .
[16:00] <skaet>  Schedule is at:
[16:00] <skaet>  #link https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
[16:00] <skaet>  #link http://fridge.ubuntu.com/calendars/ubuntu-release-calendar/
[16:00] <skaet>  .
[16:00] <skaet>  Bugs committed to be fixed by the engineering teams can be found:
[16:00] <skaet>  #link http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html
[16:00] <pitti> still roundtable today, or free-form questions?
[16:00] <skaet> Bugs that you would like the engineering teams to consider for fixing, should be assigned to specific teams, so they can be found.
[16:00] <skaet> .
[16:00] <skaet> Upcoming Dates:
[16:01] <skaet> • 2012/02/02 - Beta 1
[16:01] <skaet> .
[16:01] <skaet> Now in BetaFreeze ( as well as UserInterfaceFreeze, FeatureFreeze).  Thank you to those who got their fixes in before the Freeze.  :)
[16:01] <arosales> Hello
[16:01] <skaet> .
[16:01] <skaet> Thank you from release team to stgraber for getting queuebot working on the unapproved queue last night - makes things much easier to keep on top of.  :)
[16:01] <skaet> .
[16:01] <skaet> CD images are oversized,  so figuring out options to cut down the size of some packages/etc. would be appreciated.
[16:01] <skaet> .
[16:01] <skaet> If time permits (ie. we end less than an hour), there will be a discussion at the end on some restructuring of this meeting,   possibly using an open forum for Q&A rather than explicit round table.   But for today again, we'll continue with round table.
[16:01] <skaet> ..
[16:01] <skaet> pitti,  still round table today.    want the discussion to happen first.
[16:01] <pitti> o/
[16:01] <skaet> before we switch
[16:01] <skaet> go pitti.
[16:01] <pitti> wrt CD size, we just got a new ffox/tbird which should save ~ 2 or 2.5 MB each
[16:02] <pitti> skaet: will that be a topic of its own?
[16:02] <pitti> if so, I'll just wait
[16:02] <skaet> yes
[16:02] <pitti> ack, ..
[16:03] <skaet> ok, on to round table, and then if we don't figure it out during round table,  image pruning topic at end.
[16:03] <skaet> [TOPIC] Hardware Certification team update - mlegris
[16:03] <mlegris> [link]https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000886.html
[16:03] <mlegris> no big updated besides checkbox changing to Qt
[16:03] <mlegris> any questions?
[16:04] <Riddell> mlegris: ooh where can I test that?
[16:04] <mlegris> Riddell: yes, you can now :)
[16:04]  * skaet points Riddell to mletgis's email...
[16:04] <Riddell> got it :)
[16:05] <skaet> [Topic] QA team update -  jibel
[16:05]  * Riddell already got nessita to fix a problem in ubuntuone Qt :)
[16:05] <jibel> hi
[16:05] <jibel> [link] https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000885.html
[16:06] <jibel> upgrade bug 940252 is caused by a very bad probe effect of the code that capture debconf prompt
[16:06] <nessita> Riddell: want me to fix something else? :-D
[16:06]  * nessita fixes
[16:06] <pitti> jibel: oh, curious
[16:06] <jibel> it is disabled for the moment and in return there a new bug with kde-runtime that fails to upgrade from lucid
[16:07] <jibel> bug 940396
[16:07] <jibel> ..
[16:07] <skaet> jibel,  looks like there will be some things to dig into indeed.   Thanks for flagging them now.
[16:07]  * skaet contemplates foundation team will be busy for next couple of days...
[16:07] <Riddell> jibel: hmm interesting.  I did my smoke test on oneiric upgrade and that was fine, guess I'll need to do lucid now
[16:08] <skaet> Thanks jibel (and mlegris).  :)
[16:09] <skaet> [Topic] Security team update - mdeslaur
[16:09] <mdeslaur> [LINK] https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000872.html
[16:09] <mdeslaur> apparmor upload is imminent
[16:09] <mdeslaur> nothing further
[16:10] <mdeslaur> any questions?
[16:10] <mdeslaur> ..
[16:10] <skaet> thanks mdeslaur.
[16:11] <skaet> apw,    will next kernel after beta 1 have the upstream commit security requests?
[16:11]  * apw doesn't know off the top of his head, will look
[16:11] <skaet> thanks
[16:11] <skaet> [Topic] Kernel team update -apw
[16:12] <apw> [LINK] https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000874.html
[16:12] <apw>  
[16:12] <apw> There has been a new development in the RC6 patch we applied.  An
[16:12] <apw> additional fix has been proposed from upstream which has been confirmed to
[16:12] <apw> resolve the graphics corruption issues seen on some Samsung model's when
[16:12] <apw> RC6 is enabled by default.  We're still waiting on feedback if it also
[16:12] <apw> resolves the hard shutdown issues seen on ASUS UX31E's.  We do consider
[16:12] <apw> these critical issues to fix before release and believe it does warrant a
[16:12] <apw> Beta Freeze exception.  This change is key to our RC6 testing as we are
[16:12] <apw> unable to request the valid upstream combinations without it.  As such,
[16:12] <apw> we have requested and received approval from the release team to upload.
[16:12] <apw> The upload was done about 10 minutes ago, we will be monitoring.
[16:12] <apw>  
[16:12] <apw> ..
[16:12] <apw> skaet, on the apparmor patches, i don't think we have them yet so depend when they drop ..
[16:12] <ScottK> Kernel is accepted and building now.
[16:13] <skaet> Thanks apw.
[16:13] <arosales> apw:  Is the RC6 bug, 937378?
[16:13] <arosales> looks to be so
[16:14] <apw> that looks to be the regression yes ...
[16:14] <apw> still waiting on testing there by the looks of it ..
[16:14] <arosales> apw, it looks like the other one mentioned on the wiki is 935965. Any other feeback? Testers reporting good power savings? Seems like it would be pretty advantageous, thanks for adding it :-)
[16:15] <apw> yes those who it works for are seeing 10's of percent improvement
[16:15] <arosales> good to hear, makes my battery happy :-)
[16:16] <skaet> [TOPIC] Foundations team Q&A - stgraber
[16:16]  * stgraber waves
[16:16] <Riddell> I accepted the linux uploaded a little while ago
[16:16] <stgraber> https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000878.html
[16:16] <stgraber> questions?
[16:17] <Riddell> stgraber: nothing else for beta?
[16:17] <stgraber> (I added a few comments to bug 926859 trying to explain why using compiz with llvmpipe by default is a bad idea)
[16:17] <stgraber> Riddell: installer fixes ;)
[16:17] <ScottK> Will the updated kernel also need a DI upload?
[16:17] <stgraber> but besides that, no, I think we're pretty much done with features now that whoopsie is in
[16:18] <stgraber> ScottK: AFAICS there wasn't an ABI bump, so no, unless we care about the RC6 fix in the netinstall images
[16:18]  * ScottK guesses we don't.
[16:19] <skaet> Riddell,  yeah see jibel's QA email...  :)
[16:19] <stgraber> I assumed that too, so there shouldn't be a d-i rebuilt for beta-1 (I refreshed it yesterday already)
[16:19] <stgraber> unless something else breaks obviously...
[16:19] <skaet> thanks stgraber good to know.
[16:19] <stgraber> ..
[16:20] <Riddell> a bug free ubiquity is nice for a beta
[16:20] <skaet> dbarth,  can you comment on the compiz issues in your section...
[16:20] <stgraber> Riddell: not sure I can promise that ;)
[16:20]  * skaet figures he wants to look up the details ;)
[16:21] <stgraber> but all beta1 targeted installer bugs should be fixed early next week and probably a bunch more
[16:21] <skaet> Thanks stgraber for getting the queuebot working on the unapproved queue.   MUCH APPRECIATED!.  :)
[16:21] <stgraber> ..
[16:21] <stgraber> skaet: np, was surprisingly easy to rewrite ;) I think I spent more time trying to find the existing code than rewriting it from scratch ;)
[16:22] <Daviey> stgraber: you re-wrote it from scratch?!
[16:22] <skaet> stgraber,  awsome.   Lets make sure its checked in and accessible so we don't go through this exercise again.  :)
[16:22] <stgraber> skaet: it also allows for monitoring of other queues like New if that's something useful for #ubuntu-release
[16:23] <stgraber> Daviey: yeah ... well, current version is < 60 lines of code, so wasn't exactly difficult ;)
[16:23] <stgraber> ..
[16:23] <skaet> stgraber,  yes,  that would be.   Lets talk about it in the #ubuntu-release channel after the meeting.
[16:24]  * skaet wonders if it can say who accepted the unapproved too... ?  but later.  :)
[16:24] <skaet> [TOPIC] Server team Q&A - arosales
[16:24] <arosales> https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000887.html
[16:24] <arosales> Apologies for the late post once again. We'll get our game together soon.
[16:24] <arosales> Not a lot of new items to report on this week. OpenStack keystone-lite will replace keystone in the next week.
[16:24] <arosales> Any questions?
[16:24] <Riddell> arosales: uploads in unapproved?
[16:25] <Riddell> swift?
[16:25] <Riddell> nova?  python-novaclient?
[16:25] <arosales> Daviey: any updates on swift ^
[16:25] <Daviey> Hey
[16:25] <Riddell> there are, and we need to be told why they're important for beta
[16:26] <Daviey> Riddell: What part of it?
[16:26] <Daviey> (can you expand the question)
[16:26] <Riddell> Daviey: we'll do this in #u-release
[16:26] <pitti> they don't link to any RC bugs (or other bugs)
[16:26] <pitti> so need a separate explanation
[16:26] <Daviey> Riddell: right... So.. for the last few releases it's been something which has been followed.
[16:26] <Daviey> We track usptream to completition, where they track our dev cycle.
[16:27] <Daviey> It has a good functional and unit test suite.
[16:27] <Daviey> If this is a process we should re-visit, then we can have that as a seperate discussion
[16:27] <Riddell> Daviey: all fine, what's the reason to upload during beta freeze?
[16:27] <Daviey> https://jenkins.qa.ubuntu.com/view/Precise%20OpenStack%20Testing/ , is there to add confidence
[16:28] <skaet> arosales,  is bug 924739 any ETA when this is likely to land?
[16:28] <Daviey> Riddell: In retrospect, it could probably have been held back.. However, i'd quite like it to land in the beta.
[16:29]  * skaet wondering if in time for beta or if this is release note material?
[16:29] <arosales> skaet: I need to check on an ETA with Adam, but the issue has been identified as far as the config.
[16:29] <Riddell> ok, a cheeky late upload, you can buy me and skaet and pitti beers to get it through
[16:29] <skaet> thanks arosales. :)
[16:30] <arosales> skaet: I'll follow up with you later today
[16:30] <pitti> arosales, Daviey: so you shall have it, accepted
[16:31] <skaet> [TOPIC] ARM team?   Q&A - ogra_
[16:31] <Daviey> pitti: thanks :)
[16:31] <ogra_> sooo ...
[16:31] <ogra_> let me shock you guys a bit :)
[16:31] <arosales> pitti: Riddell: skaet: thanks :-)
[16:31] <ogra_> there was no mail for ubuntu-arm ... since there is no ubuntu-arm anymore ...
[16:32] <ScottK> Where did it go?
[16:32] <ogra_> from monday on it is expected that all platform teams care for their arm bits themselves
[16:32] <ogra_> so i would like to ask Daviey to report for arm server issues, stgraber for arm foundation issues, pitti for arm desktop etc ...
[16:32] <ogra_> the team itself got spread across platform
[16:33] <pitti> yes, makes sense
[16:33]  * skaet nods
[16:33] <ogra_> and indeed if you have arm issues, feel free to contact people from the former arm team during the transition time
[16:33] <pitti> FWIW, we already tracked arm* stuff the same like x86 in stable+1 and other tracking, but of course so far we relied on the arm team to sort out the difficult failurres
[16:33] <ogra_> theoretically every team was supposed to have an arm person during the transition ,... desktop somehow didnt get one though
[16:34] <ogra_> right
[16:34] <stgraber> oh, and I'd like to welcome ogra_ and infinity in the Foundations team (starting on Monday)!
[16:34] <ogra_> the expectation is that arm doesnt get treated differently from x86 or amd64 from now on
[16:34] <ogra_> heh, yeah, adam and i are in foundations now ... still caring for arm stuff ... but in the place where it should be cared for (platform)
[16:35] <ogra_> not in some elite team or so :)
[16:35] <ogra_> ..
[16:35]  * skaet is glad to see ogra_ and infinity in foundations team too.  :)
[16:35] <Daviey> I'd rather see them in server :)
[16:36] <skaet> Thanks ogra_!
[16:36] <ogra_> Daviey, ask victorp, probably he can help here ;)
[16:36] <Riddell> ogra_: so desktop should be hiring someone?
[16:36] <pitti> well, we don't hire an amd64 person
[16:36] <ogra_> right
[16:37] <pitti> I guess we just need to get some arm hardware
[16:37] <Riddell> pitti: ok but do we have the hardware and skills needed?
[16:37] <pitti> hardware, no
[16:37] <ogra_> yeah, your manager should approve a panda or so
[16:37] <Riddell> pitti: I do, but I need time and help to set it up
[16:37] <victorp> Daviey we could move you to foudations as a swap :)
[16:37] <pitti> skills> I expect most of the difficult stuff (compiler, linux) to not live in desktop anyway
[16:37] <ogra_> victorp, lol
[16:37] <pitti> so far any arm issue I looked at was relatively easy
[16:37] <ogra_> if its not LibO or mono, thats true
[16:37] <Riddell> pitti: graphics is fiddly for arm, anything using gl
[16:37] <ogra_> there are a bunch of nasty packages
[16:37] <ogra_> ..
[16:37] <Riddell> and of course qt and the qreal fun
[16:38] <pitti> it took me two days to fix a postgresql bug, but I guess in cases like theses we can still knock on infinity's or janimo's door and ask kindly
[16:38] <ScottK> Riddell: Those are at least easy (if tiring)
[16:38] <ogra_> right
[16:38] <pitti> Riddell: true that
[16:38] <Riddell> ScottK: you can also rent out your arm machines to desktop for a suitably large fee
[16:38] <ogra_> the arm team isnt gone, we are just in other places
[16:38] <ScottK> Once I get a new router for that network segment.  Sure.
[16:38] <Daviey> ScottK: Talking of which... what happend to those MOTU machines?
[16:39] <Daviey> ScottK: you had 2 x ARM machines for MOTU use?
[16:39] <Riddell> ScottK: new issues aren't so easy, I couldn't work out a fix for compiz
[16:39] <Daviey> \o/
[16:39] <ScottK> Daviey: See my previous comment about dead router.
[16:39] <Riddell> ScottK: get jason to expense it
[16:39] <skaet> [TOPIC] Linaro team Q&A - fabo
[16:39] <Riddell> (but he's on holiday for the next week i think)
[16:39] <ScottK> Also they aren't hardware Ubuntu supports, so I have to rework them to a more modern release.  Probably debian testing armhf.
[16:40] <fabo_> https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000889.html
[16:40] <ScottK> Riddell: It's not the cost it's the time to drive to the store.
[16:40] <fabo_> in addition, we want to update live-build (as discussed with skaet)
[16:40] <fabo_> after beta1 might be a good timing
[16:41] <skaet> stgraber, pitti, ScottK, Riddell, ^ any thoughts about timing/concerns?
[16:41] <fabo_> Thanks to Ubuntu ARM team and see you in your new assignment :)
[16:41] <fabo_> ..
[16:41] <skaet> thanks fabo_ :)
[16:42] <ScottK> I'd suggest if it's ready now, sooner is better than later.
[16:42] <pitti> skaet: linaro builds shouldn't affect us?
[16:42] <stgraber> sorry I need a second, the linaro e-mail got on the list very late so haven't had a chance to read pre-meeting
[16:42] <skaet> pitti, thought there might be common code,  but we can carry on the discussion in #ubuntu-release after meeting.
[16:43] <stgraber> fabo_: would like to see some details on what's in that update live-build and how it'll impact Ubuntu, though #ubuntu-release is fine for that
[16:44] <fabo_> stgraber: ok, np.
[16:45] <skaet> fabo_,  any thoughts on when the smaller compiz patch (OpenGL ES2.0) will be available for review?
[16:45] <fabo_> skaet: no ideas right now, but asap. it's a high prio
[16:46] <skaet> fabo_,  fair 'nuf.  Thanks.
[16:46] <skaet> [TOPIC] Desktop Team Q&A  - pitti
[16:46] <pitti> report at https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000880.html
[16:46] <pitti> st landed new firefox/tbird with an estimated 5 MB saving of CD space, leaving some 3 or 4 to be taken off
[16:46] <pitti> option 1 (and my preferred one) is to drop python3 again by switching lsb-release back to python2; lsb-release is currently the only package using python3 on the CD, so we'd carry those 4.5 MBs just for this
[16:47] <pitti> the default option is as always to kick off yet another langpack; we only have Spanish, Portugese, and Chinese left to sacrifice now, though
[16:47] <pitti> ..
[16:47] <pitti> ScottK, doko, stgraber: any opinion on python3?
[16:47] <ogra_> skaet, i'll still take care for that patch on teh plkatform side ... no worries, i'll keep you updated
[16:47] <ogra_> ..
[16:47] <Riddell> pitti: any reason not to drop python3?
[16:47]  * skaet thanks ogra_ :)
[16:47] <ScottK> pitti: Removing it would make barry very sad.
[16:48] <pitti> I bet
[16:48] <ScottK> Other than that, I think it's fine.
[16:48] <pitti> but carrying it for a 20 line lsb-release script seems a bit heavy
[16:48]  * ScottK agrees.
[16:48] <doko> pitti: apport still not using python3? lame ...
[16:48] <pitti> doko: -ENOLAUNCHPADLIB
[16:48] <pitti> at least from next cycle on we'll have bigger image sizes
[16:49] <stgraber> I tend to agree carrying a full language for just a 20 lines script sounds like a waste of space, it's sad not more stuff are using python3 yet though
[16:49] <ScottK> Dropping it would help all the images, right?
[16:49] <pitti> yes
[16:49] <doko> pitti: please check with barry, I'm fine with it
[16:49] <pitti> ack
[16:50] <skaet> Thanks pitti.   sounds like we have a decision.
[16:50]  * skaet won't bring it up at end now.... ;)
[16:50] <pitti> I'll prepare the upload after barry acks
[16:50] <skaet> any other questions for desktop before moving on? ...
[16:51] <skaet> [TOPIC] Unity Framework Team Q&A - dbarth
[16:51] <skaet> hmm... don't see dbarth in the channel...
[16:52] <skaet> [TOPIC] Unity Services and Settings Team  Q&A - Cimi
[16:52] <Cimi> hello!
[16:52] <Cimi> [LINK] https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000884.html
[16:52] <Cimi> Yet another intense week for the team :-)
[16:52] <Cimi> as you can see, lots of bugs fixed
[16:53] <Cimi> thanks to Coverity as well, nice work from the QA team and our engineer
[16:53] <Cimi> we were able to spot new bugs and improve the quality of our libraries
[16:53] <Cimi> on the FFe/UIFes
[16:54] <Cimi> I've updated the list with the remaining links
[16:54] <Cimi> I'd like to hear your feedback on this side, if there's any
[16:54] <Cimi> especially on the the two requests of the GMenuModel in Hud, and extended support for XUL apps
[16:55] <Cimi> we're not sure they should be considered as bugfixes or exceptions
[16:56] <Cimi> on the UIFe, I think there shouldn't be problems for the 1st one, the 2nd I was currently working on
[16:56] <Cimi> I'll try to make the change really subtle (and not as in the bugreport community contribution)
[16:56] <Cimi> I'm open to all your requests
[16:56] <Cimi> ..
[16:57] <skaet> pitti, any concerns from desktop team on the FFes/UIFes  ?
[16:57] <pitti> I haven't actually seen a lot from DX?
[16:58] <pitti> we got two metric tons from online services
[16:58] <pitti> (or I don't remember any more)
[16:58] <Riddell> pitti: "tonnes" :)
[16:58] <skaet> heh,  yeah its that time in the release... memory stack overflow for all.
[16:59] <skaet> Cimi,  thanks for the details.   Will follow up after meeting.
[17:00] <Cimi> cool
[17:00] <Cimi> I think I'm done then, all silent means all good :-)
[17:00] <skaet> Thanks to the team for all the bug fixes.  :)
[17:01] <Cimi> our pleasure and our job :)
[17:01] <skaet> yup silence is good. :)
[17:01] <skaet> [TOPIC] Kubuntu Team Q&A - Riddell
[17:01] <Riddell> hi
[17:02] <Riddell> https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000888.html
[17:02] <Riddell> still more politics than coding but kubuntu-active might appear any time now
[17:02] <Riddell> ..
[17:02] <skaet> Thanks Riddell.
[17:03]  * skaet figures that Riddell gets to teach the publishers about it,  if its ready for B1 - so that issue will get handled ;)
[17:03] <skaet> [TOPIC] Edubuntu Team Q&A - stgraber or highvoltage
[17:03] <stgraber> https://lists.ubuntu.com/archives/ubuntu-release/2012-February/000875.html
[17:04] <stgraber> I think we're in pretty good shape for beta-1 now and don't expect much to change for this cycle
[17:04] <skaet> :)
[17:04]  * skaet glad to hear that
[17:04] <stgraber> we'll probably get more bugfix releases of epoptes and LTSP but both projects are in feature freeze too
[17:04] <stgraber> ..
[17:04] <skaet> Thanks stgraber.:)
[17:05] <skaet> [TOPIC] Xubuntu Team Q&A - madnick
[17:05]  * skaet sees madnick in the channel.... 
[17:05] <skaet> any other xubuntu folk around?
[17:07] <skaet> not seeing ubuntu studio folk either,  and lubuntu said they'll not make it.
[17:07] <skaet> [TOPIC] MOTU Team Q&A - tumbleweed or Laney
[17:07]  * ScottK knows there's a GHC6 transition going on.
[17:08] <skaet> thanks ScottK.
[17:08] <skaet> just a reminder to all,  if an unseeded universe package/fix is ready - please highlight that on #ubuntu-release channel, so we can let it through during the beta freeze.
[17:09] <ScottK> I'm been pushing them through as I see them.
[17:09] <ScottK> I'm / I've
[17:09] <skaet> thanks ScottK.  :)
[17:09] <skaet> [TOPIC] Any other business, comments,  questions?
[17:09] <pitti> me too, yes
[17:09] <ScottK> I'm guessing that what's in queue for the powerpc builders already will have them busy most of the weekend.  There's LO and two openjdk uploads that aren't even started yet.  Particularly since it's gcc and a kernel build in progress now.
[17:09] <pitti> skaet: meeting format/
[17:10] <skaet> pitti,  ok - we're over the hour, but yes..  :)
[17:10] <Riddell> I'd rather have an open meeting
[17:10] <skaet> Proposal on the table is to change the format of this meeting
[17:10] <Riddell> it would encourage me to send the e-mail earlier
[17:10] <skaet> to an open meeting,  rather than a round table.
[17:10] <Riddell> and to read over other e-mails if skaet pinged 30 mins before the meeting :)
[17:10] <pitti> so we'll throw in questions instead of waiting for our turn
[17:11] <skaet> For this to work,  e-mails will need to be in 2 hours before the meeting.
[17:11] <ScottK> Sending the mails doesn't seem to have shortened the meeting as it is.
[17:11] <pitti> yes, the idea was to read the mails before theh meeting and then have questions ready
[17:11] <pitti> well, it used to be 1.5 hours
[17:11] <Riddell> the current format is too much waiting for no good reason
[17:11] <pitti> but I guess many people do other stuff at the side, which probably slows it down as a whole
[17:11]  * pitti is guilty of that himself
[17:11] <skaet> If folks can get their emails in we can try the open format after the initial annonce.
[17:11] <ScottK> Could we just have a discussion on the mail list and do away with the meeting?
[17:12] <Riddell> nah meeting is useful
[17:12] <skaet> ScottK,  its efficient for some issues to get resolved to have this meeting.
[17:12] <highvoltage> oops, I missed the Edubuntu part (I guess that's a problem with the waiting, you get distracted :) )
[17:12] <Riddell> but it can be short without all the waiting
[17:12] <Riddell> highvoltage++
[17:12] <ScottK> OK.  Maybe people should ask their questions on the list as much as possible too.
[17:12] <pitti> yes, I think IRC has better turnarounds
[17:12] <skaet> ScottK ++
[17:13] <ScottK> pitti: Sure, but let's keep the meeting to the stuff that really needs to be real time.
[17:13] <pitti> but we could certainly do 30 intense minutes (or less in some meetings which aren't right before a beta) instead of the waiting round
[17:13] <Riddell> skaet: can you send a reminder to send e-mails and another one 30 mins before meeting to read over them?
[17:13] <pitti> ScottK: right, and we did resolve questions on the ML before, too (I agree, when possible that makes sense)
[17:14] <skaet> Riddell,   its early in the morning for me,  rather this just be a self reminding cron job for folks if they need reminders.
[17:14]  * arosales will work on getting Server team update in a timely manner
[17:15] <skaet> all in favor of having emails in 2 hours before,  and going to open forum Q&A session,  please vote  +1,  all wanting to keep with current round table -1 please.....  anyone know the runes?
[17:15]  * skaet figures there's a way to trigger the vote and get those quiet ones to weigh in..
[17:15] <Riddell> skaet: cron is fine :)
[17:15] <pitti> #vote
[17:16]  * skaet thanks pitti
[17:16] <Riddell> +1
[17:16] <stgraber> skaet: #vote subject of the vote
[17:16] <pitti> only skaet can issue it
[17:16]  * Riddell out
[17:16] <skaet> #vote change meeting to open Q&A rather than round table.
[17:16] <meetingology> Please vote on: change meeting to open Q&A rather than round table.
[17:16] <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)
[17:16] <pitti> Riddell: hm, I just read them as they come in
[17:16] <pitti> +1
[17:16] <meetingology> +1 received from pitti
[17:16] <mdeslaur> +1
[17:16] <meetingology> +1 received from mdeslaur
[17:17] <stgraber> +1 [Please send your team reports early ...]
[17:17] <meetingology> +1 [Please send your team reports early ...] received from stgraber
[17:17] <arosales> +1
[17:17] <meetingology> +1 received from arosales
[17:17] <fabo_> +1
[17:17] <meetingology> +1 received from fabo_
[17:18] <skaet> jibel, mlegris, apw ^ any thoughts?
[17:18] <skaet> Cimi ^?
[17:18] <jibel> +!
[17:18] <jibel> +1
[17:18] <meetingology> +1 received from jibel
[17:18] <apw> +0
[17:18] <meetingology> +0 received from apw
[17:18] <skaet> +0
[17:18] <meetingology> +0 received from skaet
[17:20]  * skaet not seeing any more votes,  but seems we probably have quorum
[17:20] <pitti> skaet: #endvote
[17:20] <skaet> #endvote
[17:20] <meetingology> Voting ended on: change meeting to open Q&A rather than round table.
[17:20] <meetingology> Votes for:6 Votes against:0 Abstentions:2
[17:20] <meetingology> Motion carried
[17:20]  * skaet thanks pitti  :)
[17:21] <skaet> Thanks mlegris, jibel, mdeslaur, apw, stgraber, arosales, ogra_, fabo, pitti, dbarth, Cimi, Riddell,  ScottK
[17:21] <mdeslaur> thanks skaet
[17:21] <skaet> #endmeeting
[17:21] <meetingology> Meeting ended Fri Feb 24 17:21:17 2012 UTC.
[17:21] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-24-16.00.moin.txt
[17:21] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-24-16.00.html
[17:21] <Cimi> thanks skaet
[17:21] <jibel> thanks skaet
[17:21] <pitti> thanks everyone!
[17:21] <arosales> thanks skaet
[17:22] <stgraber> thanks!
[17:22] <Daviey> woo, thanks
[18:01] <wendar> o/
[18:01] <coolbhavi> hi wendar
[18:02] <ajmitch> wendar: want to chair? I'm running on not much sleep right now :)
[18:02] <wendar> ajmitch: sure
[18:02] <coolbhavi> ajmitch, me too late night here :)
[18:02] <wendar> #startmeeting
[18:02] <meetingology> Meeting started Fri Feb 24 18:02:48 2012 UTC.  The chair is wendar. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:02] <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
[18:03] <ajmitch> .wi n56
[18:03] <ajmitch> as you can see...
[18:03] <wendar> [Link] https://wiki.ubuntu.com/AppReviewBoard/Agenda
[18:03] <wendar> no past actions to review
[18:04] <wendar> are stgraber and mhall119 here?
[18:04]  * ajmitch cleared off the past meeting items as they were decided at the meeting
[18:04]  * stgraber waves
[18:04] <wendar> ajmitch: yes, that's good
[18:04] <ajmitch> hi stgraber
[18:05] <mhall119> o/
[18:05] <wendar> ah, excellent
[18:05] <coolbhavi> hi mhall119
[18:05] <mhall119> hi
[18:05] <wendar> [TOPIC] Discuss acceptance criteria for separate Unity Lens and Scope packages
[18:06] <wendar> So, this was discussed in the TB meeting this week.
[18:06] <wendar> And, they are willing to make an exception that allows scopes to be packaged separately from their related lenses, if the ARB recommends that as the best solution.
[18:07] <mhall119> Does everybody have a clear understanding of what I'm asking for and why?
[18:07] <wendar> Where we are now is basically: Does this make sense?
[18:07] <wendar> Or, on a deeper level: How are we going to manage the process of approving Scopes and Lenses so it doesn't overload us, risk poor quality, or set bad precedents for the future?
[18:08] <wendar> Whatever we choose, does impact our workflow.
[18:08] <wendar> mhall119: How about a quick summary?
[18:08] <mhall119> after our meeting with the TB, stgraber send a proposal to the ARB mailing list that I think would satisfy the need of lens/scope developers, without compromising the stability of the extras archive, and I am +1 on his proposal
[18:08] <ajmitch> mhall119: can you give a (very) brief explanation of what a lense does & what a scope does
[18:09] <mhall119> Quick summary: Lenses and scopes can be written independently of eachother, and we want to allow authors to submit them to the ARB separately
[18:09] <mhall119> the current rules of the ARB don't allow the scope's package to Depend on the len's package
[18:09] <mhall119> but without that Depends, you can have someone installing a scope they can't use
[18:10] <coolbhavi> mhall119, I just found out that in the ARB review shift past week
[18:11] <mhall119> a Lens provides UI information to the Unity Dash, a Scope provides search results to the Dash, to be displayed according to the Lens
[18:11] <mhall119> A Scope needs to know about it's Lens, but a Lens doesn't need to know about the Scopes that use it
[18:12] <wendar> [LINK] https://lists.ubuntu.com/archives/app-review-board/2012-February/000484.html
[18:12] <mhall119> so what I'm seeking is a way for a Scope author to submit their scope without the Lens author having to be involved
[18:14] <wendar> good summary, thanks
[18:14] <wendar> has everyone read stgraber's post from earlier this week?
[18:14] <wendar> (the link above)
[18:14] <mhall119> again, I am +1 on stgraber's recommended (in that link) and would be willing to help with the initial packaging
[18:15] <coolbhavi> yes
[18:15] <ajmitch> mhall119: the one problem in that mail from stgraber is that each scope would need to be updated by users if a new one is added for the lense - how many scopes do you see being created per lens?
[18:15] <mhall119> my only concern is how much added work it will be for the ARB to handle all the packaging of lenses and scopes
[18:16] <wendar> yes, I think we need to talk in more detail about how this solution might work
[18:16] <wendar> I'm assuming we'd maintain a team bzr branch for each Lens
[18:16] <ajmitch> it's not a lot of extra work to have them as one source package in a branch, from what I can see
[18:16] <mhall119> ajmitch: as few as 0 external scopes, and probably commonly 5-6 external scopes, but could be more
[18:16] <wendar> in which case, we can accept scope submissions as merge proposals
[18:16] <wendar> which would significantly lessen the load
[18:17] <wendar> I also had a question about upgrades
[18:17] <wendar> since upgrading to a new Ubuntu release (i.e. Oneiric->Precise) is a resubmission for Extras
[18:17] <wendar> that would mean that we drop all scopes, start fresh with the Lens, and accept any new scope submissions for the new release
[18:18] <stgraber_> sorry looks like I can't reach hetzner from here at the moment (and so lost my IRC session ...)
[18:18] <wendar> which would save us the work of upgrading all the independent scopes for incompatible API changes
[18:18] <mhall119> wendar: is that because of the API change, or will this happen at every release?
[18:18] <stgraber_> last I got was "18:12 < mhall119> so what I'm seeking is a way for a Scope author to submit their scope without the Lens author having to be involved", can someone paste me what I missed in private?
[18:18] <wendar> mhall119: this is standard for all Extras apps
[18:19] <wendar> mhal119: we don't do any upgrades, just resubmissions
[18:19] <mhall119> wendar: ok, so all packages(even the lens) would need to be re-submitted?
[18:19] <stgraber_> yes
[18:19] <wendar> mhall119: now, the author may resubmit what is essentially just a straight copy of the old app updated for the new release
[18:20] <wendar> mhall119: this allows for an easy "dropping off" effect of old apps where the author hasn't taken the trouble to make them work on the new release
[18:20] <mhall119> wendar: ok, so this proposal wouldn't change that, it just means that the ARB would have to handle updating the packaging every release
[18:20] <wendar> mhall119: right, this wouldn't change the policy
[18:20] <mhall119> ok
[18:20] <ajmitch> mhall119: I expect that from precise onwards, the lens API should be pretty stable?
[18:21] <wendar> mhall119: well, I'm suggesting the ARB wouldn't even have to handle much in the way of updating the packaging
[18:21] <coolbhavi> wendar, seems good enough keeping API changes in view like a new version based on old one
[18:21] <wendar> mhall119: if we treat each new release as "start over with the Lens"
[18:21] <stgraber_> ajmitch: thanks for the copy/paste
[18:21] <mhall119> ajmitch: I've been told that it won't change, under penalty of death
[18:21] <ajmitch> heh
[18:21] <wendar> mhall119: that's good :)
[18:22] <mhall119> of course, they said that before they changed it last time too :)
[18:22] <stgraber_> so to answer the ARB time issue with my proposed solution, my feeling is that it'd actually be much faster than what we do at the moment
[18:22] <wendar> mainly, I'm looking for ways to mitigate the load on the ARB, and the "resubmit at each new Ubuntu release" is definitely one or them
[18:22] <stgraber_> currently we need to review a full package every time if not actually do one for them (in most cases ...)
[18:22] <stgraber_> with my proposal we could have something completely templated that we just copy/paste when we get the lens
[18:23] <ajmitch> a couple of small issues that I can see - need a single debian/copyright for the source package, and need to integrate build systems as lenses & scopes can be written in anything that talks dbus
[18:23] <stgraber_> and from that point on, adding a scope is just copying two files and adding a debian/control and debian/changelog entry
[18:23] <ajmitch> stgraber_: that's assuming they're just written in python, rather than compiled from vala
[18:23] <mhall119> ajmitch: can we limit this to just python lenses and scopes for the time being?
[18:23] <wendar> stgraber: yes, one of the things I mentioned when you were temporarily off IRC is that with your proposal scope submissions could take the form of branch merge proposals to the ARB branch for the Lens
[18:23] <wendar> stgraber: which would be nice and simple
[18:23] <ajmitch> mhall119: gladly
[18:24] <ajmitch> but someone would need to explain to contributors why we only take certain scopes & not others
[18:24] <wendar> ajmitch: the single debian/copyright file would list the copyrights for each author separately
[18:24] <stgraber_> correct, debian/copyright should be easy to do using DEP5
[18:24] <ajmitch> wendar: right, easy to list them, someone has to do the work to put it together
[18:24] <stgraber_> so far all the lenses and scopes have been trivial python script, these are easy to deal with on the packaging side
[18:24] <ajmitch> whether that be by some automated method
[18:24] <wendar> ajmitch: indeed
[18:24] <stgraber_> I indeed expect any C lens/scope to be much harder though
[18:25] <mhall119> the vast, vast majority of community-developed lenses and scopes are python
[18:25] <wendar> ajmitch: ah, that is a good point, we should talk with the pkg-me devs about getting lens/scope packaging into their automated tools
[18:25] <mhall119> in fact, I don't know of any that aren't
[18:25] <wendar> (not for Oneiric, but can help down the road)
[18:26] <ajmitch> mhall119: there are examples in vala
[18:26] <mhall119> ajmitch: yes, but we can reasonably assume that most will be in Python
[18:26] <wendar> stgraber: the lenses/scopes I've written have all been in vala, they're still pretty simple and straightforward
[18:26] <ajmitch> wendar: mhall119 has been working on getting his lens/scope stuff into quickly, so it helps on that end :)
[18:26] <mhall119> especially with Singlet + a Quickly template being in 12.04
[18:26] <wendar> stgraber: it's a good API
[18:27] <stgraber> (back from here)
[18:27] <wendar> so, if Quickly had an "add a new scope" option, that could make our lives really simple
[18:27] <ajmitch> so at the moment, we're mostly +1 on the proposal, for python lenses/scopes?
[18:27] <mhall119> wendar: which is technically possible
[18:27] <wendar> mhall119: yup
[18:28] <wendar> ajmitch: yes, I'm in favor of stgraber's proposal
[18:28] <wendar> ajmitch: we have some details to work out, but it's good overall
[18:28] <mhall119> an added benefit of stgraber's proposal is that it doesn't require any rules changes
[18:28] <ajmitch> mhall119: it'd be really nice to get unity to reload its list of lenses without reloading :)
[18:28] <ajmitch> wendar: great
[18:28] <mhall119> ajmitch: yeah, that's low on their priority list though, so unless someone outside of DX does it, it's not likely for 12.04
[18:28] <wendar> should we carry it to a vote?
[18:28] <stgraber> ajmitch: oh yeah, that one is really annoying ;)
[18:29] <ajmitch> wendar: might need to set #voters, but yeah
[18:29] <mhall119> ajmitch: I've got unity building locally, and trying to understand enough C++ to implement the fix myself, but don't count on it
[18:29] <ajmitch> mhall119: yeah, I took a brief walk through the code to see how possible it'd be
[18:30] <ajmitch> maybe I need to sit down with thomi & have him explain it :)
[18:30] <mhall119> ajmitch: mhr3 was helping me, njpatel would be a good person to talk to as well
[18:30] <wendar> #vote To approve stgraber's proposal for handling Lenses and Scopes in ARB managed combined packages
[18:30] <meetingology> Please vote on: To approve stgraber's proposal for handling Lenses and Scopes in ARB managed combined packages
[18:30] <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)
[18:30] <wendar> +1
[18:30] <meetingology> +1 received from wendar
[18:30] <ajmitch> +1
[18:30] <meetingology> +1 received from ajmitch
[18:31] <stgraber> +1
[18:31] <meetingology> +1 received from stgraber
[18:31] <ajmitch> coolbhavi: still awake? :)
[18:31] <coolbhavi> +1 provided resubmission cycle doesnt have overloading effect
[18:31] <meetingology> +1 provided resubmission cycle doesnt have overloading effect received from coolbhavi
[18:31] <wendar> #endvote
[18:31] <meetingology> Voting ended on: To approve stgraber's proposal for handling Lenses and Scopes in ARB managed combined packages
[18:31] <meetingology> Votes for:4 Votes against:0 Abstentions:0
[18:31] <meetingology> Motion carried
[18:32] <wendar> We can review how this went at the start of the Precise cycle, and decide if we need to make any changes.
[18:32] <ajmitch> ok, now to take it to the TB list, should get it passed there quickly
[18:32] <mhall119> does this still need to go to the TB, since it's not a rule change?
[18:32] <wendar> ajmitch: actually, since we aren't making any policy changes, they won't need to vote
[18:32] <ajmitch> wendar: even better
[18:32] <wendar> ajmitch: but, I'll summarize and post to the TB list, so they know for the next meeting
[18:33] <ajmitch> thanks
[18:33] <mhall119> I propose we start with a single lens+scope combination to work out the kinks and get a package template, would you like to target Oneiric or Precise?
[18:33] <wendar> mhall119: we can start setting up the first repos this afternoon if you have time
[18:33] <mhall119> wendar: I do
[18:33] <wendar> mhall119: Oneiric for now
[18:33] <mhall119> ok
[18:33] <wendar> mhall119: so start with any Lenses that use the Oneiric APIs
[18:34] <wendar> thanks mhall119!
[18:34] <mhall119> wendar: I'll pick a couple of candidates, and send them to the ARB's mailing list?
[18:34] <mhall119> or should I submit them through MyApps?
[18:34] <wendar> mhall119: if you want to discuss which are most appropriate to start with, we can talk on the list or IRC
[18:35] <stgraber_> mhall119: look at the unity-lens-utilities one as an example
[18:35] <wendar> mhall119: but, if you're pretty certain, go ahead and submitt to MyApps
[18:35] <stgraber_> mhall119: it currently contains a lens and two scopes
[18:35] <wendar> mhall119: that way it's in the queue
[18:35] <stgraber_> mhall119: all of them in python and all of them nicely protected by apparmor
[18:35] <mhall119> stgraber_: that's already in USC isn't it?
[18:35] <stgraber_> mhall119: yep, that one is already in extras
[18:35] <stgraber_> mhall119: so you can just look at the branch and re-use for the others
[18:36] <mhall119> stgraber_: ok, so we'll use that as a packaging template, and I'll find a new candidate for our first run
[18:36] <stgraber_> mhall119: http://code.launchpad.net/~stgraber/+junk/arb-utilities-lens/
[18:36] <coolbhavi> mhall119 I would be interested in testing lenses+scopes out in oneiric as I pointed out past week
[18:37] <mhall119> coolbhavi: check the onehundredscopes project on LP, there's a bunch of them there
[18:37] <wendar> coolbhavi: great!
[18:38] <coolbhavi> mhall119, sure will pull them this weekend and have a look. Thanks!
[18:38] <wendar> a few quick other agenda items
[18:38] <wendar> [TOPIC] Policy check on QMuttNotifier (indicator, rather than stand-alone app)
[18:39] <wendar> I'm suggesting that we reject this one.
[18:39] <mhall119> thanks everyone for bearing with me and helping find a resolution on this
[18:39] <ajmitch> imo, indicators are fine - they're standalone enough
[18:39] <wendar> mhall119: thank you, and we look forward to seeing those Lenses and Scopes coming through :)
[18:39] <mhall119> so do I?
[18:39] <ajmitch> not trying to be contrary, but they've got similar desktop integration requirements that lenses do
[18:40] <mhall119> :), not ?
[18:40] <stgraber_> I think indicators should be fine, as long as they live in /opt and just ship the required desktop file out of it and properly namespaced
[18:41] <stgraber_> obviously depending on exactly what the indicator does though
[18:41] <wendar> it says it requires konsole
[18:41] <stgraber_> oh, that sounds wrong ;)
[18:41] <ajmitch> it's because it pops up a terminal to load mutt in
[18:41] <stgraber_> sure but we have x-terminal-emulator for that
[18:41] <wendar> which violates our "no command-line apps" policy
[18:41] <ajmitch> not sure how kde-dependent the rest of the code is, and if we're wanting to accept things for other desktops :)
[18:42] <wendar> though, in an indirect way
[18:42] <ajmitch> very indirect, the no command-line apps was mostly due to PATH
[18:42] <wendar> I brought it to discuss, because it's a bit of an edge case
[18:42] <stgraber_> well, our policy says we don't accept command line apps, this one isn't, it just calls one ;)
[18:43] <ajmitch> I think it's an edge case for a different reason - does the software centre separate things by desktop environment, or indicate somehow that it's for kde?
[18:43] <wendar> aye, we don't have a specific security requirement about launching other command-line apps from GUI apps
[18:43] <wendar> ajmitch: not currently, no
[18:43] <wendar> It just seems like the kind of thing Kubuntu should be reviewing
[18:44] <wendar> If people would prefer, I can bounce it back with our new policy of requiring a PPA
[18:45] <wendar> so, the author would need to resubmit
[18:45] <wendar> but, I didn't want to do that if there was no chance we'd ever accept it
[18:45] <wendar> it doesn't seem fair to ask the author for a bunch of work and then say "Sorry, we can't accept it"
[18:45] <ajmitch> right, I don't think we have any policy on derivatives, or if we should
[18:46] <wendar> It currently doesn't even have build instructions, just bare source code.
[18:47] <wendar> I could also simply ask how heavily this depends on KDE
[18:47] <coolbhavi> wendar, then I m also a bit skeptical because the software centre doesnt categorize it under different DE's but we can have it in the description that its for kde. But is there an option to launch mutt without cli? havent tried it though
[18:47] <wendar> like, if it's a KDE indicator, rather than a Unity indicator, and installing it would essentially pull in KDE as a dependency
[18:48] <wendar> then, that would violate our policies about modifying low-level system components
[18:49] <ajmitch> wendar: I just built it, it doesn't pull in any KDE libs, just Qt
[18:50] <wendar> ajmitch: did you install it? does it integrate with the Oneiric Unity indicators?
[18:50] <ajmitch> wendar: I haven't installed it, just tried running it in-place on precise
[18:50] <coolbhavi> people sorry have to leave because m getting very sleepy
[18:50] <ajmitch> it complained about ~/.muttrc not existing & didn't get further than that
[18:50] <wendar> okay, thanks coolbhavi, we're just about done
[18:51] <ajmitch> coolbhavi: ok, thanks for being here :)
[18:51] <wendar> Sounds like the general consensus is that we could accept this.
[18:52] <wendar> So, I'll go ahead and ask him to make the usual fixes.
[18:52] <ajmitch> if it's not going to break a normal desktop, it should be ok
[18:52] <wendar> [TOPIC] Policy check on EasyISO (filesystem mount/unmount utility)
[18:52] <ajmitch> the author should probably check ~/.mutt/muttrc as well :)
[18:53] <stgraber> wendar: mount/unmount requires root and so gksudo => reject
[18:53] <ajmitch> this is just for ISOs, can't it be done with FUSE?
[18:54] <wendar> a quick grep shows that it's using fuseiso
[18:55] <ajmitch> so it doesn't look like it should need any root privileges in that case
[18:55] <wendar> [LINK] https://myapps.developer.ubuntu.com/dev/apps/655/
[18:56] <wendar> ajmitch: I can't say that for sure until I do the full code review
[18:56] <stgraber> if it never uses root permissions, then I guess it's fine
[18:56] <ajmitch> wendar: it currently fails if fuseiso isn't installed
[18:56] <wendar> ajmitch: that would mean fuseiso would be a package dependency
[18:57] <ajmitch> yep
[18:57] <ajmitch> it's in universe
[18:57] <wendar> ajmitch: that's okay, Extras are allowed to depend on universe
[18:58] <wendar> it's enabled by default
[18:58] <ajmitch> right, was just mentioning that it's at least packaged already :)
[18:58] <broder> can't nautilus do something like that already?
[18:58] <ajmitch> sorry if I'm not making much sense, still waking up
[18:58] <wendar> my main question was whether this was appropriate at all for Extras
[18:58] <wendar> as in, it's more of a filesystem tool than an "app"
[18:59] <wendar> with the potential to interfere with other filesystem tools (like nautilus)
[19:00] <wendar> like, what if there's some race condition on who mounts what when and where?
[19:00] <broder> gvfs can already open iso files and expose them through gvfs-fuse - is there more of a value add here than mounting the iso at an arbitrary path?
[19:00] <ajmitch> when I run the app, it looks extremely basic
[19:01] <wendar> "Apps should be useful or interesting to a general audience. "
[19:01] <wendar> is it?
[19:02] <wendar> We're at the end of our time
[19:02] <stgraber> if gvfs takes care of the use case already, then there's not much point in the app
[19:02] <stgraber> other than making the feature more visible to the user
[19:02] <ajmitch> at a glance I think it's potentially useful for exposing it in an easy way
[19:03] <wendar> Sounds like this will need more general discussion.
[19:04] <wendar> so, carry to the mailing list
[19:04] <ajmitch> ok
[19:04] <wendar> one last thing
[19:04] <wendar> [TOPIC] General status of ARB queue
[19:04] <wendar> We're actually doing quite well.
[19:04] <wendar> Only 20 apps in the queue.
[19:04] <wendar> of which, 5 are new
[19:04] <wendar> Some lingering issues for the MyApps developers:
[19:05]  * ajmitch needs to catch up & push stuff to voting once little things like patching are sorted :)
[19:05] <wendar> - We need a way to list apps that are waiting for replys from the developer
[19:05] <ajmitch> does someone want to take ubuntu-tweak & reply to the feedback?
[19:05] <wendar> - We're waiting on the patch application that will allow us to drop apps that have already launched from the queue, instead of keeping them forever in Pending QA status.
[19:06] <wendar> ajmitch: Can we switch back to only having reviewers "own" one app at a time?
[19:06] <wendar> ajmitch: I'm running out of things to package.
[19:06] <ajmitch> wendar: of course
[19:07] <wendar> ajmitch: which one are you currently working on?
[19:07] <ajmitch> tagplayer
[19:07] <wendar> cool, I'll leave that one
[19:07] <ajmitch> I don't want to be a blocker on anything else
[19:07] <wendar> I'll do a general mailing list post and make sure I'm not working over the top of anyone else.
[19:08] <wendar> I think once we clear out some of the backlog, we'll be in good shape
[19:08] <wendar> The "new" submissions are pretty easy to tend in a couple of hours a week
[19:08] <wendar> so, the review shifts will take care of them
[19:09] <wendar> And, that's all.
[19:09] <wendar> ajmitch: are you following up with dpitkin on the changes to see apps waiting for feedback?
[19:10] <wendar> ajmitch: should I note that as an action item for you?
[19:10] <ajmitch> yes, it's on my weekend todo list
[19:10] <wendar> sweet, thanks!
[19:10] <wendar> And, thanks everybody!
[19:10] <wendar> #endmeeting
[19:10] <meetingology> Meeting ended Fri Feb 24 19:10:50 2012 UTC.
[19:10] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-24-18.02.moin.txt
[19:10] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-24-18.02.html
[19:10] <stgraber> thanks!
[19:10] <ajmitch> thanks
[19:12] <wendar> ajmitch: I can look at ubuntu-tweak this afternoon
[19:15] <ajmitch> wendar: alright