Started logging meeting in #ubuntu-meeting
[09:00:43] <pitti> hello
[09:00:45] <mdz> [topic] Action review
[09:00:52] <mdz> [link] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000784.html
[09:01:28] <mdz> I missed the previous meeting, so please correct me if I've missed anything
[09:01:32] <pitti> KDE microversion SRU docs has happened
[09:01:53] <mdz> it looks like there were no actions per se, though there were a couple of things which should be back on the agenda for this meeting
[09:02:09] <mdz> couchdb & U1 on 10.04
[09:02:16] <pitti> right, the couchdb SRU and post-maverick updates
[09:02:22] <mdz> pitti: what is the status of the ARB exception proposal?
[09:02:45] <pitti> it was discussed a bit after the last meeting, but I didn't see much news there
[09:02:48] <mdz> ok
[09:02:50] <pitti> it sounded like 90% of an agreement
[09:02:55] <wendar> we ran out of time
[09:02:56] <mdz> is Chipaca around?
[09:03:09] <pitti> hey wendar
[09:03:33] <wendar> hi pitti
[09:03:43] <mdz> hi Chipaca
[09:03:48] <Chipaca> hi mdz
[09:03:48] <wendar> I've got a reply in the moderation queue again, if someone could give it a push before we get to that point in the agenda
[09:03:51] <mdz> [link] https://wiki.ubuntu.com/TechnicalBoardAgenda
[09:04:12] <mdz> wendar: there are no messages in the moderation queue for technical-board
[09:04:14] <pitti> wendar: ah, your reply just hit the list
[09:04:26] <mdz> [topic] couchdb lucid backport SRU - John Lenton
[09:04:57] <mdz> so I missed the previous meeting, but have talked with Chipaca a little bit out of band
[09:05:06] <pitti> that was also discussed on the TB ML
[09:05:13] <pitti> with some updates from yesterday/today
[09:05:20] <mdz> according to the minutes, the TB proposed an alternative solution and asked the U1 team to evaluate it
[09:05:34] <mdz> ah, I hadn't read the latest
[09:05:44] <mdz> pitti: would you like to guide the discussion?
[09:05:48] <pitti> the alternative solution was proposed to ship a separate couchdb-1.0 package in lucid-updates
[09:06:04] <pitti> mdz: yes, can do
[09:06:08] <pitti> hello Chipaca
[09:06:14] <Chipaca> I need to bbiab, this battery is running out and i've got the wrong charger. give me a minute please.
[09:06:22] <mdz> [link] https://lists.ubuntu.com/archives/technical-board/2010-November/000590.html
[09:06:36] <mdz> is the latest from Chipaca on the mailing list
[09:07:38] <pitti> right, and https://lists.ubuntu.com/archives/technical-board/2010-November/000592.html my latest reply
[09:09:06] <mdz> so Chipaca is saying that it's not feasible, from the sound of it
[09:09:13] <pitti> I'm interested in why
[09:09:34] <Chipaca> hi, back
[09:09:43] <mdz> * while we can introduce a couchdb-1.0-bin package into 10.04 to
[09:09:43] <mdz> address this issue, we can't really make it co-exist on the same
[09:09:43] <mdz> machine wiht a 0.10 couchdb-bin, so it would have to conflict with
[09:09:43] <mdz> it; additionally, we'd have to get a SRU for a client package in
[09:09:43] <mdz> 10.04 (either desktopcouch or ubuntuone-client would work) so that
[09:09:44] <mdz> the 1.0 package gets pulled in, and an additional SRU for 10.10 to
[09:09:46] <mdz> get the dependency fixed.
[09:10:04] <pitti> when we update the main couchdb package, I'd frankly feel overwhelmed, and that we deliberately break API and stability (and thus working setups) in favor of enabling features
[09:10:09] <mdz> pitti, I believe you questioned the co-existence point
[09:10:28] <pitti> right, I'm curious why it wouldn't work
[09:10:54] <mdz> I'm inferring from Chipaca's tone that perhaps it just seems like too much work
[09:11:08] <Chipaca> it could be made to work, in the "it's just software" sense. We can't make it work in that it would be a big change, as we'd have to add code to let desktopcouch start the right version of couch
[09:11:39] <pitti> and AFAIK it doesn't auto-migrate existing databases over to the 1.0 format, right?
[09:12:00] <Chipaca> couchdb auto-migrates, yes
[09:12:16] <Chipaca> the way we're shipping the system couchdb explicitly avoids the auto-migration
[09:12:21] <Chipaca> by adding the version number to the path to the database
[09:13:35] <pitti> so this would help making both co-installable
[09:14:35] <Chipaca> what does co-installation try to fix?
[09:14:51] <mdz> Chipaca: it seems like decoupling desktopcouch from the system-wide couchdb might be a good long-term move
[09:15:35] <mdz> it would enable you to update "your" couchdb without risking breakage in other couchdb applications
[09:15:37] <pitti> Chipaca: not breaking the database API for existing insallations
[09:16:00] <mdz> Chipaca: otherwise we will surely face exactly this same choice the next time you want to update
[09:16:34] <mdz> do you need help getting the packaging right?
[09:17:03] <mdz> or do you feel this is not the best solution?
[09:17:17] <Chipaca> the problem is not the packaging, which yes I will probably need help with because of resources, the problem is afaik starting and connecting to the "right" couchdb from desktopcouch
[09:17:57] <pitti> if we can auto-migrate user databases, then we could switch desktopcouch to use 1.0?
[09:18:22] <pitti> as far as I remember, the desktopcouch API wouldn't change
[09:19:30] <Chipaca> right, we'd update the desktopcouch package to depend on 1.0, and then we'd have to make desktopcouch start 1.0
[09:19:52] <mdz> Chipaca: I guess I don't understand why that's hard
[09:20:03] <pitti> and don't we need to do that either way?
[09:20:09] <pitti> adapting desktopcouch to start 1.0, I mean
[09:20:19] <mdz> start_local_couchdb.py seems pretty straightforward
[09:20:32] <thisfred> pitti: well not if it were the only couchdb :)
[09:20:37] <thisfred> mdz, not super hard, it just means an extra SRU
[09:20:50] <mdz> it looks like it will already DTRT if the COUCHDB environment variable is set to an alternative binary
[09:20:55] <thisfred> which I don't think we'll get around anyway
[09:21:05] <Chipaca> and modifying desktopcouch in that sru in a way that won't be as tested as what we're replacing
[09:21:06] <mdz> thisfred: an extra compared to what?
[09:21:12] <mdz> surely desktopcouch needs to be updated anyway
[09:21:34] <Chipaca> the difference is between updating just the packaging, and updating the code also
[09:21:34] <thisfred> mdz, it would not if we updated the system couchdb
[09:21:43] <thisfred> which I know we won't
[09:22:59] <mdz> thisfred: so if a 10.04 system gets couchdb updated to 1.0, the broken bits of U1 start working with no other changes?
[09:23:38] <thisfred> yep
[09:23:45] <Chipaca> pitti: the difference is that if we make the packages conflict, we get away with not touching desktopcouch code, which is a good thing for a stable release, right?
[09:24:11] <pitti> well, it's not the lines of code that we change
[09:24:21] <pitti> by that measure, introducing a new package would be way off scale
[09:24:32] <pitti> it's about the greatest possible damage we can do to existing working setups
[09:25:01] <pitti> Chipaca: if we make the packages conflict, then we couldn't pull in couchdb-1.0 automatically during upgrade
[09:25:05] <pitti> since couchdb is already installed
[09:25:13] <pitti> and the entire exercise would be moot, wouldn't it?
[09:25:14] <mdz> pitti++
[09:25:18] <mdz> it's about risk
[09:25:27] <rickspencer3> may I offer my opinion?
[09:25:31] <mdz> of course
[09:25:35] <rickspencer3> (even if people won't like it?)
[09:25:39] <pitti> and we can't just force-remove couchdb
[09:25:45] <pitti> rickspencer3: please
[09:25:51] <rickspencer3> My view is that CouchDB missed the Lucid the train
[09:26:06] <rickspencer3> I understand this is painful as we would like to provide services to Lucid users
[09:26:19] <rickspencer3> However, I feel this effort is now misdirected
[09:27:19] <mdz> I think there is a way this could be done which would sufficiently contain the risk to 10.04 users, such that we would be comfortable releasing it
[09:27:31] <thisfred> I respectfully disagree, I think the side-by-side solution is still worth the (little extra) effort, if the TB approves it
[09:27:37] <mdz> but it will be up to the U1 team whether that effort would be well spent
[09:27:45] <rickspencer3> it's not just effort on their part
[09:27:47] <pitti> right, with pretty much parallel packages
[09:28:03] <thisfred> pitti: yep
[09:28:04] <rickspencer3> this will cause effort to be expended across the organization
[09:28:20] <mdz> it may be that effort would be better invested in making the changes in natty such that we can issue future updates without a problem
[09:28:25] <rickspencer3> and Chipaca already said they lack the resources themselves to do proper packaging
[09:28:36] <pitti> thisfred: I have no objections against a side-by-side approach; it still requires a formal exceptoin, as it's outside of the usual SRU boundaries, but it has a manageable risk, so I'd agree to it
[09:28:47] <mdz> I'm with pitti
[09:29:00] <rickspencer3> well, I don't think it's worth the risk or the effort
[09:29:11] <pitti> but yes, mdz raises a good point -- we should make sure that if this happens again we are better prepared
[09:29:16] <rickspencer3> and the effort is not just on the U1 team
[09:29:48] <pitti> perhaps we should have a separate desktopdouch-server package which just talks to desktopcouch, and not use the "official" couchdb package at all
[09:29:58] <mdz> rickspencer3: fair point, there is other effort involved which perhaps we haven't included in our implicit estimate
[09:30:14] <mdz> I'm not prepared to offer the U1 team advice on whether this is worth it or not, at least not with my TB hat on
[09:30:24] <mdz> but they are welcome to ask me for my Canonical opinion separately
[09:30:38] <rickspencer3> mdz, well, with my Director of Engineering hat on, I feel I should offer my views
[09:30:41] <thisfred> just as a thought experiment, if we were to put couchdb 1.0 in backports
[09:30:49] <thisfred> would that be acceptable?
[09:30:57] <pitti> yes IMHO
[09:31:09] <rickspencer3> isn't that specifically what backports if for?
[09:31:09] <pitti> we make no promises wrt. API stability in backports
[09:31:14] <Chipaca> backports are not enabled by default, right?
[09:31:17] <pitti> correct
[09:31:19] <Chipaca> ok
[09:31:22] <mdz> I do feel that, based on the analysis I've seen, and the survey results, updating the couchdb package itself is not in the best interest of our user base as a whole
[09:31:24] <pitti> which is why we can be liberal there
[09:31:31] <thisfred> Of course most people using lucid for stability reasons won't have backports on...
[09:31:47] <mdz> rickspencer3: you absolutely should. I'm just explaining why I'm neither agreeing nor disagreeing with you :-)
[09:31:53] <pitti> thisfred: so people who care about U1 syncing, and don't need existing couchdb could just grab it from backports, you mean?
[09:31:54] <rickspencer3> right
[09:32:07] <thisfred> pitti: yeah
[09:32:17] <mdz> couchdb 1.0 in backports is OK with me as well, and I expect the backports team would be amenable
[09:32:27] <thisfred> pitti: though the downside is that they'd have to be made aware of this
[09:32:32] <pitti> it would mean backports of couchdb and desktopcouch; anything else?
[09:32:48] <mdz> thisfred: it would also entail testing both upgrade paths, if you want to support those users properly
[09:32:57] <thisfred> pitti: nope, and not even desktopcouch if we don't do the parallel install there
[09:33:21] <aquarius> thisfred, couch 1.0 doesn't need a newer spidermonkey?
[09:33:32] <pitti> thisfred: lucid's desktopcouch doesn't need updates to talk to an 1.0 couchdb API? that did change
[09:34:15] <thisfred> pitti: no, the API (that desktopcouch cares about) did not change between 0.10 and 1.0
[09:34:44] <pitti> thisfred: but anyway, I could even envision an SRU which checks for this situation if you try to enable non-file sync, and guides you to a website which explains the situation and how to install backports
[09:34:45] <thisfred> pitti: we'd only need to make changes to d-c if we were to have the parallel install
[09:35:20] <pitti> thisfred: ok, then couchdb backport plus changes to point to documentation ("install couchdb from backports; don't if you have existing couchdb...") seems feasible?
[09:35:32] <mdz> option 1: parallel package couchdb 1.0, update desktopcouch to use it, and release via SRU exception
[09:35:49] <mdz> option 2: parallel package couchdb 1.0, update desktopcouch to use it, and release via backports
[09:35:54] <thisfred> aquarius: I thought not, but that still doesn't impact desktopcouch. It would mean another SRU if it's true and we don't go the backports route
[09:36:08] <Chipaca> oh, I was reading option 2 as non-parallel
[09:36:09] <mdz> option 3: update couchdb to 1.0 in backports, superseding 0.1 in lucid
[09:36:12] <pitti> mdz: I think option 2 is "backport maverick couchdb", no parallel install, right?
[09:36:14] <Chipaca> ah
[09:36:16] <pitti> ah, right
[09:36:19] <Chipaca> it's 0.10, not 0.1 :)
[09:36:24] <mdz> Chipaca: sorry
[09:36:28] <mdz> s/0.1/0.10/
[09:36:32] <pitti> I think we can rule out 2
[09:36:43] <pitti> it's almost as much effort as 1 but a lot less benefit
[09:36:47] <thisfred> right
[09:36:53] <mdz> ok
[09:36:59] <rickspencer3> mdz is there not an option to simply move on?
[09:37:07] <Chipaca> and about the sru of the control panel to alert users of the availability of the fix, is tehre agreement on that?
[09:37:13] <mdz> option 4: do nothing, focus on natty, move on
[09:37:22] <mdz> rickspencer3: yes!
[09:37:26] <rickspencer3> :)
[09:37:29] <mdz> any other options?
[09:37:53] <Chipaca> mdz: does option 2 include the ubuntuone-preferences sru to alert users of the issue?
[09:38:04] <Chipaca> um, option 3 i meant
[09:38:06] <pitti> mdz's option list seems complete to me
[09:38:15] <aquarius> "option 5: backport 1.0 to lucid, breaking people who are reliant on specific aspects of 0.10 in lucid" is entirely off the table, yes?
[09:38:19] <mdz> Chipaca: I'm not familiar with that idea
[09:38:31] <aquarius> (er, s/backport/SRU/, sorry)
[09:38:37] <Chipaca> thisfred: but anyway, I could even envision an SRU which checks for this situation if you try to enable non-file sync, and guides you to a website which explains the situation and how to install backports
[09:38:41] <Chipaca> mdz: ^
[09:38:50] <rickspencer3> wow
[09:39:00] <pitti> aquarius: I'd vote against it, so you'd need to convince another majority of the TB
[09:39:12] <aquarius> pitti, just making sure the option list is complete. :)
[09:39:14] <mdz> aquarius: I'm with pitti
[09:39:27] <pitti> aquarius: but yes, it'd complete the option list
[09:40:31] <mdz> Chipaca: thinking
[09:40:54] <rickspencer3> well, I guess there are options that the TB would accept, and then options that Ubuntu Engineering would be willing to support with resources
[09:40:59] <rickspencer3> that list may not be the same
[09:41:09] <mdz> so this would be a minimal SRU which changed the software to notify the user of the situation and how to proceed?
[09:41:46] <pitti> (raises some questions wrt. adding translatable strings, and translating the web page, but I think we could fit that in)
[09:41:52] <mdz> I think that could be done in a way that would be acceptable to the SRU team
[09:42:12] <pitti> or skip the web page and try to come up with a short text
[09:42:49] <mdz> any objections to dropping option 2 because it's dominated by the others?
[09:43:12] <thisfred> mdz +1 on dropping 2.
[09:43:14] <mdz> done
[09:43:27] <mdz> option 1: parallel package couchdb 1.0, update desktopcouch to use it, and release via SRU exception
[09:43:29] <mdz> option 3: update couchdb to 1.0 in backports, superseding 0.1 in lucid
[09:43:33] <mdz> option 4: do nothing, focus on natty, move on
[09:43:34] <pitti> mdz: +1 on dropping 2
[09:43:53] <pitti> thisfred, aquarius: hm, we could even check if there are local systemwide couchdbs
[09:44:00] <pitti> and only show that note if there aren't
[09:44:01] <mdz> benefits of 1: might make future updates easier
[09:44:25] <mdz> costs of 1: relatively large development and testing effort
[09:44:35] <mdz> benefits of 3: relatively small development and testing effort
[09:44:36] <aquarius> pitti, which is basically defined by "do you have the couchdb package installed", because that's what provides the system couchdb (d-c depends on couchdb-bin, which provides the binaries etc but not the init scripts and so on)
[09:44:52] <pitti> 1 sounds like a good future path from natty on (i. e. have a desktopcouch-private couchdb server package)
[09:44:59] <mdz> benefits of 3: zero impact to users who do not use U1
[09:45:07] <pitti> aquarius: could be; that, or checking the data dir
[09:45:16] <mdz> disadvantages of 3: more fiddly for users who do use U1
[09:45:36] <pitti> mdz: "... want to use more features of U1"
[09:45:48] <mdz> pitti: ack
[09:46:17] <mdz> benefits of 4: zero development and testing effort, strong focus on current development and forward momentum
[09:46:36] <mdz> disadvantage of 4: disappoint people who want the new features on LTS
[09:46:56] <mdz> what else have I missed?
[09:46:58] <aquarius> mdz: "...who want the *existing* features on LTS"
[09:47:02] <Chipaca> another disadvantage of 4: for a non-ignorable number of people, ubuntu one will (continue to be) "just file sync"
[09:47:13] <mdz> aquarius: did they actually lose features they had when 10.04 came out?
[09:47:23] <pitti> mdz: thanks for summarizing; looks complete to me
[09:47:33] <Chipaca> mdz: yes, the features worked on release
[09:47:39] <Chipaca> mdz: and then buckled under load
[09:48:04] <mdz> ok, so we had to regress them in order to get it working for anybody
[09:48:07] <rickspencer3> well, it worked on the client, but from the users point of view, it did not work
[09:48:25] <mdz> and they probably didn't use it for very long
[09:48:38] <mdz> in effect, it shipped without the functionality, no?
[09:48:43] <mdz> it = 10.04
[09:48:45] <rickspencer3> in effect
[09:49:22] <mdz> is there anything more for the TB to decide?
[09:49:24] <rickspencer3> you could/can store data in couchdb, but there is no syncing and it fails silently
[09:49:30] <thisfred> in effect yes, as we had to disable replication on the server very soon after release
[09:49:34] <Chipaca> i disagree with rickspencer3, but I know we disagree
[09:50:07] <mdz> we've outlined multiple options and evaluated the pros and cons, I think the final call is up to the U1 team as to which is the best use of their energy
[09:50:13] <pitti> with my TB hat on, I'd approve any of 1, 3, 4
[09:50:30] <pitti> with my developer hat on, I think we should at least do 3
[09:50:36] <mdz> we have another item on the agenda which wendar has been waiting patiently to discuss
[09:50:44] <pitti> then clean up the situation in natty (with an approach like 1)
[09:50:55] <pitti> and then perhaps reconsider later on if this can be backported
[09:51:13] <Chipaca> mdz: to make things clear, we decide which way forward is best, and the TB approves of it?
[09:51:22] <Chipaca> of these options
[09:52:11] <pitti> sounds fine
[09:52:31] <pitti> Chipaca: but it seems you can do any of above option, and it'd get the TB's approval
[09:52:34] <mdz> Chipaca: yes, pretty much. I think we need some oversight on the details if it's 1 or 3
[09:52:45] <mdz> so we should stay in touch
[09:52:57] <mdz> but you would have our blessing
[09:53:16] <Chipaca> ok, thank you
[09:53:31] <mdz> [topic] ARB exception proposal - Allison Randal
[09:53:37] <mdz> wendar, thanks for your patience
[09:53:52] <wendar> IIRC, there's another meeting here on the hour. A quick summary:
[09:53:58] <wendar> - Allow .desktop files to be installed outside /opt.
[09:54:00] <wendar> - In Natty, we'll modify Quickly, cdbs, python-support, and related packages o support installation in /opt.
[09:54:01] <wendar> - For Maverick, accept that .pyc files and version symlinks won't be generated for Python libraries.
[09:54:03] <wendar> - For Maverick, ARB will perform manual package fixes on proposed applications, to install in /opt and load libraries from /opt.
[09:54:04] <wendar> - Binaries only in /opt (no exceptions for Maverick), will not be in $PATH.
[09:54:06] <wendar> - Official install location is /opt/extras.ubuntu.com/ (with version number? i.e. "/opt/extras.ubuntu.com/foo-1.5")
[09:55:04] <pitti> (for the record, natty's cdbs/quickly/etc. already support this)
[09:55:23] <wendar> The last we would especially like decided today, as the modifications for Natty packages are ready to go but waiting on that path to be finalized before merging.
[09:55:57] <persia> Why except .desktop files: couldn't they be pulled by extending DefaultAppDirs in some package in extras upon which things depend?
[09:56:21] <wendar> persia: no part of the system knows how to pull .desktop files from non-standard paths
[09:56:33] <mdz> wendar: I'm a bit concerned on behalf of the ARB about the expectation that they will fix up the packages as needed
[09:56:40] <wendar> persia: we can modify it for Natty, but not for Maverick
[09:56:54] <mdz> but I guess you can speak for yourselves on that point?
[09:57:07] <wendar> mdz: yes, that manual work is not something we could do for the long-term, but for Maverick we have few submissions
[09:57:14] <wendar> mdz: only 4 at the moment
[09:57:24] <persia> wendar, The menu-xdg package has an implementation that pulls from /var/lib/menu-xdg/applications/menu-xdg
[09:57:32] <pitti> persia: can you extend the .desktop search path with an extra conffile?
[09:57:39] <persia> pitti, Yep.
[09:57:44] <pitti> (I know, *I* ought to know this, but I don't, sorry)
[09:58:05] <persia> Well, I should say you *could*. I haven't dug deeply in menus for > 18 months.
[09:58:14] <mdz> wendar: binaries only in /opt = "binaries nowhere else but in /opt", not "nothing in /opt which is not a binary", right?
[09:58:28] <wendar> persia: can we modify it to pull .desktop files from /opt/extras.ubuntu.com/applications without modifying any system packages?
[09:58:30] <pitti> /etc/xdg/menus/applications.menu just says
[09:58:54] <pitti> but my concern is that this would need modification of gnome-menus, the KDE counterpart, and any other desktop env
[09:58:58] <persia> wendar, I believe so, but it would take me a few hours to chase the how.
[09:59:27] <pitti> mdz: confirmed; it's "no files outside /opt", except perhaps .desktop
[09:59:57] <wendar> pitti: yes
[10:00:07] <mdz> the .pyc and symlink stuff is definitely OK by me
[10:00:14] <mdz> if the ARB is ok with fixing up the packages, I'm OK with t hat too
[10:00:26] <mdz> no-binaries-outside-of-/opt seems sensible enough
[10:00:37] <mdz> the extras.ubuntu.com path also sounds fine
[10:00:45] <mdz> so the only question is about how to handle .desktop files?
[10:01:06] <wendar> yes, just .desktop
[10:01:19] <mdz> I don't know how many programs use /usr/share/applications
[10:01:20] <wendar> and, whether to use the path /opt/extras.ubuntu.com/
[10:01:38] <mdz> but AIUI the standardized interface is the filesystem
[10:01:52] <persia> mdz, ~90%, and everything with a menu entry uses that or a subdirectory.
[10:01:54] <wendar> mdz: the intention is that most of these apps will be using .desktop files
[10:01:55] <mdz> is it not workable to install the .desktop files in /opt and symlink them to /usr?
[10:02:13] <wendar> mdz: yes, a symlink would be workable
[10:02:14] <mdz> persia: I meant, how many programs *read* the list of .desktop files
[10:02:36] <wendar> mdz: it would still pollute the general namespace, but preserves the principle of "install in /opt"
[10:02:43] <mdz> wendar: a symlink would at least give correct behavior if the stuff in /opt went away
[10:02:46] <persia> Oh. Six, last I counted (7.10)
[10:02:53] <mdz> but if that's managed by the package manager, I don't suppose that's a problem
[10:03:00] <mdz> I'm happy either way
[10:03:00] <pitti> I don't see much difference between symlink and actually installing into /u/s/a/, but symlink sounds fine
[10:03:20] <mdz> pitti: I was thinking of opt as something which is managed outside of the package manager, but in this case of course it isn 't
[10:03:26] <wendar> okay, so approved a symlink for .desktop files outside /opt?
[10:03:30] <mdz> I was worried about dangling .deskto pfiles
[10:03:39] <pitti> wendar: would be interesting to investigate enlarging the search path in natty
[10:03:46] <wendar> and I'll work with persia to see if we can get actual load from /opt working
[10:03:46] <mdz> wendar: I think it's unnecessary complexity, installing directly in /usr should be OK
[10:03:47] <pitti> to pick up desktop files in /opt
[10:04:01] <mdz> (installing .desktop files in /usr, I mean, of course)
[10:04:02] <pitti> ^ especially since these get manual review for sanity
[10:04:21] <persia> wendar, Sounds good. I know we have some implementations that *change* the menu files in various ways with additional packages: just needs some digging to get the right XML.
[10:04:31] <wendar> then, approved to install .desktop files in /opt, if we can't find a workaround for Maverick
[10:04:44] <wendar> for Natty, we should have .desktop files in /opt working
[10:04:49] <mdz> we don't actually have a quorum of the TB here, I don't think
[10:04:58] <pitti> wendar: you mean "approved .. in /usr/s/apps/"
[10:04:59] <mdz> so if you need an official vote or something, we'll have to take it to email
[10:05:06] <wendar> pitti: aye
[10:05:09] <mdz> but it sounds sane to me
[10:05:19] <pitti> but that has already been brought up on the list without opposition
[10:05:26] <mdz> we need to clear out to let the server team have their meeting
[10:05:27] <pitti> great
[10:05:38] <wendar> then, last thing: /opt/extras.ubuntu.com/?
[10:05:48] <pitti> +1 (as I said on the ML)
[10:05:53] <mdz> wendar: I said +1 above as well
[10:06:00] <mdz> done?
[10:06:08] <wendar> done, thanks!
[10:06:11] <mdz> I don't see anything else on the mailing list
[10:06:14] <mdz> so that's a wrap, thanks all
[10:06:17] <mdz> #endmeeting