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