=== JackyAlcine_ is now known as JackyAlcine === webjadmin is now known as JackyAlcine === webjadmin_ is now known as JackyAlcine === fenris is now known as Guest47832 === Guest47832 is now known as ejat === Ursinha` is now known as Ursinha === Ursinha is now known as Guest37626 === lag` is now known as lag === ttx` is now known as ttx === popey_ is now known as popey === chrisccoulson_ is now known as chrisccoulson === shadeslayer_ is now known as shadeslayer === tsimpson_ is now known as tsimpson === greyback is now known as greyback|lunch === yofel_ is now known as yofel === greyback|lunch is now known as greyback [15:58] o/ [15:59] hello! [16:01] OK, we should get started [16:01] yay [16:01] #startmeeting [16:01] Meeting started Mon Feb 20 16:01:21 2012 UTC. The chair is ara. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [16:01] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired [16:01] welcome to the Ubuntu Friendly meeting #34 [16:01] #topic Optical drive testing for Ubuntu Friendly (roadmr) === meetingology changed the topic of #ubuntu-meeting to: Optical drive testing for Ubuntu Friendly (roadmr) [16:02] hi all! [16:02] The situation is as follows. We now have a very nice automated CD writing test [16:03] what it does is, it asks for blank media, writes some files to it, and then tries to read them [16:03] this enables us to test reading and writing with just one test, thus being quicker for the user [16:03] the problem is, the way the test was designed, it would be the *only* CD test run [16:03] and the consequence for Ubuntu Friendly is that, if the drive supports writing, this test will ask the user for blank media [16:04] if the user has no blank media, the test will either fail or be skipped [16:04] o/ [16:04] and since CD functionality is considered core, we'll be giving the system one star (fail) if the user happened to not have (or not want to waste) a blank disk [16:04] So for the time being we're still using only the read test for CD, and this awesome CD writing test is not used at all :) [16:05] We'd like some feedback on how to handle this, one of the ideas being to change the "coreness" of the CD tests, making them optional/additional [16:06] another possibility would be to rework this test so it behaves differently [16:06] o/ [16:06] and yet another would be the vaunted feature where checkbox supports various exit statuses so the test can say why it didn't run and not be considered an outright failure. [16:06] So that's the situation. Ideas anyone? [16:07] ara, you're first [16:07] hey [16:07] so, basically, we have three (and not two) types of tests: optional, core and skippable core [16:07] I think we need to keep 2 tests [16:07] the read one to be core, and the write one to be skippable [16:08] to have only one for Ubuntu Friendly is not the answer [16:08] as many people would skip the write one [16:08] and in the end no one would be testing even the reading capabilities [16:08] .. [16:09] OK, yes, the original proposal was to skip the read-only test entirely if the write one was runnable [16:09] brendand: your turn [16:09] similar to what ara said [16:09] it's fairly straightforward, [16:10] any test which has a valid reason why it could not be run should be skippable [16:11] i don't see how the read one should be core though. if the tester doesn't have a disc to test with we should really give the system one star? [16:11] brendand, agree [16:11] brendand, I stand corrected, both should be skippable [16:12] jedimike, could you remind us how the optical tests are considered right now? are they core-core or core-skippable? :) [16:12] i guess in theory the wireless test for example could also not be testable, but in that case the hardware is so important it shouldn't be skippable [16:12] roadmr: let me check... [16:12] for optical media i think a penalty is enough [16:14] a further conundrum is if the drive doesn't have a write capability then it will be penalised [16:14] even though it could never be expected to support that capability [16:14] how to deal with that? [16:14] ... [16:15] optical is core, in the 11.10 tests dvd-write, cdrom-write, read_sr1 and read_sr0 are core-skippable. In 12.04 they're core-core. Do we want the mappings and skipping lists copied over to the 12.04 config now? [16:16] jedimike: for 12.04 the whitelist shows only optical/detect and optical/read, there are no more write tests (at least not on the whitelist) [16:16] roadmr: ok, the category mappings still need to be copied across though, I'll get on to that. [16:17] roadmr, jedimike: I think we need an action item to coordinate and fix the mappings for 12.04 [16:17] ara: ok. I'll get the category mappings done now, it won't take me more than a few minutes. Then we can do the skippable stuff later. Once we go to production, there'll need to be an action item to get the mappings copied from staging. [16:18] ara: also the whitelist could potentially still change, so I'd say not to set the mappings "in stone" until later [16:19] agree, but we need to start selecting the skippable [16:19] to start gathering data on staging [16:19] and be able to fix stuff [16:19] .. [16:19] ara: we can put the write test back, but keep the read one, it's a bit of duplication but it's the best way to collect all that data [16:20] ara: agreed, so the most pressing thing would be to look at the current whitelist and see how the tests are classified [16:20] anyone want to work with jedimike on this? :) [16:20] (I can do it) [16:21] [ACTION] jedimike and roadmr to review the current default checkbox whitelist to ensure core-core/core-skippable/skippable-skippable mappings still make sense [16:21] ACTION: jedimike and roadmr to review the current default checkbox whitelist to ensure core-core/core-skippable/skippable-skippable mappings still make sense [16:22] [ACTION] bladernr, roadmr and spineau to decide whether it makes sense to put the optical/write test back without removing the read one, so that functionality gets at least tested (will penalize if the user decides to skip) [16:22] ACTION: bladernr, roadmr and spineau to decide whether it makes sense to put the optical/write test back without removing the read one, so that functionality gets at least tested (will penalize if the user decides to skip) [16:22] anything else needed on this topic? [16:24] OK, let's move on! [16:24] #topic "The Eagle has landed" - Checkbox-qt now available in Precise, call for testing (roadmr) === meetingology changed the topic of #ubuntu-meeting to: "The Eagle has landed" - Checkbox-qt now available in Precise, call for testing (roadmr) [16:24] roadmr, all yours (again) [16:24] heheh :) I blame bladernr [16:24] anyway - so yes, the new and shiny checkbox-qt interface for Checkbox has landed in Ubuntu. [16:24] o/ [16:25] As usual we'd appreciate help from everyone testing it and filing bugs so we can fix them and ensure the new UI is as usable as possible. [16:25] To use it, just apt-get install checkbox-qt [16:25] and run checkbox-qt instead of checkbox-gtk [16:26] So please test and either send your comments to the mailing list or file Launchpad bugs for the stuff that bugs you! [16:26] .. [16:26] cr3: go ahead! [16:26] just to announce that we're still in the process of getting checkbox-qt on the desktop image but there's no significant blockers so far [16:26] .. [16:26] cr3: awesome, thanks! yes, for now it requires manual installation but the package is tiny so the pain should be minimal [16:28] that's all really on this topic :) [16:28] OK, any other questions or comments on the topic? [16:29] #topic AOB === meetingology changed the topic of #ubuntu-meeting to: AOB [16:29] Anybody else has any other topics to talk about? [16:29] without the else, of course [16:29] if roadmr has other topics he's more than welcome to share them :) [16:29] * roadmr has nothing else :( [16:30] going once... [16:30] going twice... [16:30] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology [16:30] Meeting ended Mon Feb 20 16:30:42 2012 UTC. [16:30] Minutes (wiki): http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-20-16.01.moin.txt [16:30] Minutes (html): http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-20-16.01.html [16:30] thanks all! [16:33] thanks! bye! === JackyAlcine_ is now known as JackyAlcine === Quintasan_ is now known as Quintasan === allison_ is now known as wendar [20:54] kees: can you chair today? cjwatson is off for enlarging his family :) [20:54] and you'd be next alphabetically I think [21:00] is the TB meeting now? [21:00] o/ [21:00] jono: Yup. [21:00] cool [21:00] Well, or supposed to be, at least. [21:00] hey soren, hows things? [21:00] * stgraber waves [21:01] hi [21:01] howdy stgraber [21:01] * mhall119 waves [21:01] jono: Gosh. Good question :) [21:01] :-) [21:02] jono: Nah, it's all good, I guess. Just almost too busy to stop and realise it. [21:02] jono: So thanks for forcing me to :) [21:02] indeed :-) [21:02] hehe [21:02] hey soren [21:02] pitti: o/ [21:02] stgraber: there? [21:02] pitti: Did you ping anyone else besides kees? [21:03] pitti: yep [21:03] soren: not yet [21:03] pinged mdz now [21:05] mhall119: are you there to discuss your topic? [21:05] seems to be our only topic today anyway [21:05] pitti: yes [21:06] I didn't scan the ML thoroughly, though, I just returned back home (was on vac today) [21:07] do we know if sabdfl can make it? [21:08] jono: he's not a regular member of TB any more, so only attending some meetings [21:08] np [21:08] so, seems kees is off as well [21:08] and I'm next on the list, so [21:08] #startmeeting [21:08] Meeting started Mon Feb 20 21:08:58 2012 UTC. The chair is pitti. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [21:08] 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 [21:09] #topic action review === meetingology changed the topic of #ubuntu-meeting to: action review [21:09] kees to perform brainstorm review [21:09] I think we can safely drop this one now, as the next one is due in March [21:09] Laney and wendar to get trademark policy updated wrt remixes [21:09] ^ do you happen to be online? [21:09] pitti: we've submitted a ticket for it [21:10] just a sec, will look for the ticket # [21:10] wendar: thanks [21:10] so, sounds like "in progress" [21:10] also, we had a suggestion about adding some information to the extension repository policy [21:11] "If the software does not allow redistribution, document this clearly in the debian/copyright file." [21:11] with supporting documentation suggesting to add this as a comment in DEP5 format [21:11] I guess remixes need to carefully go through the licenses of partner anyway [21:11] we talked some with SPDX about whether they had any standard way of tagging non-redistributable software [21:11] and, they said no [21:12] some standard comment seemed helpful [21:12] Sorry, "SPDX"? [21:12] soren: that's the group that's working on license metadata [21:12] like DEP5, but more general [21:13] What's it short for? [21:13] skaet is one of the leaders of the group [21:13] "Software Package Data Exchange" [21:13] spdx.org [21:13] Cool. Thanks. [21:13] just a side conversation to see if we could standardize on prior art [21:13] the main idea is just to provide reasonable notification to the consumers of the packages [21:14] and, something that can be scanned automatically, so it's not an enormous task of checking each package in a remix to see if you can remix the remix [21:15] But, no need to go into specific implementation details in the ExtensionRepositoryPolicy [21:15] Would you all be comfortable adding "If the software does not allow redistribution, document this clearly in the debian/copyright file." [21:15] to the current policy? [21:15] https://wiki.ubuntu.com/ExtensionRepositoryPolicy [21:15] under 2.3 "Copyright Considerations" [21:16] (no rush, can be considered and held over to the next meeting) [21:16] actually this is alreayd the point of the copyright file [21:16] but pointing it out more explicitly/machine readable sounds fine and straightforward [21:16] Yeah, I have no problem with that. [21:16] https://bugs.launchpad.net/ubuntu-website-content/+bug/933187 [21:16] Error: launchpad bug 933187 not found [21:17] nice, fix committed already [21:17] wendar: thanks for the update! [21:17] #topic Can an ARB exception be made allowing Scopes packages to depend on Lens packages in extras - mhall119 === meetingology changed the topic of #ubuntu-meeting to: Can an ARB exception be made allowing Scopes packages to depend on Lens packages in extras - mhall119 [21:18] ah, right, right now extras pacakges can only depend on Ubuntu packages, not to each other, right? [21:18] yes [21:18] pitti: right, the current policy is that one package in extras can't depend on another in extra [21:18] I see how that might be required for libraries, but what was the general reason for this? [21:18] but the Unity API encourages separate development of lenses and scopes [21:19] https://lists.ubuntu.com/archives/technical-board/2012-February/001205.html [21:20] tl;dr, it makes it harder to remove problem packages from extras if other packages in extras might depend on them [21:20] note that in the general ExtensionRepositoryPolicy, packages in Extras can depend on other packages in Extras [21:20] (FWIW, my opinion described in that ML thread hasn't changed over the past few weeks, I'm still definitely against this change) [21:20] (this is because it's generic for all) [21:20] but, Extras specifically doesn't permit libraries [21:20] If not a general rule change, I would like to at least get a specific exception for the case of lenses and scopes [21:20] independent libraries [21:21] I have a list of 61 lenses and scopes being developed [21:21] so far only 6 have gone through the ARB process [21:21] my worry here is that we have an enormous number of scopes and lenses in development, and the ARB is a perfect avenue for review and inclusion, but with this dependency restriction we are effectively blocking scopes from the ARB [21:21] 29 of those are scopes that live independently from the lens they extend [21:21] and I am not confident that the average scope/lens dev is going to be able to get their software into the archive via the traditional upload process [21:22] a lense isn't exactly a library, it's more an app for which the scopes are plugins [21:22] ajmitch: except that the Unity API allows the scope to run in a separate, independent process [21:22] and community over dbus [21:22] so if we'd pull a scope from extras, what would the lenses do? [21:23] AFAICS we'd need to remove them from extras as well, right? [21:23] mhall119: right, plugin in the data sense rather than sharing the same process [21:23] pitti: the lens tells the Dash how to display results from the scope [21:23] stgraber: So you'd prefer that people lump them together in a single binary package? [21:23] soren: into a single source package. Multiple binary from a single source is already allowed in extras [21:23] pitti: one lens can have multiple, independent scopes, that provide it with data to display in the dash [21:23] mhall119: would it not make sense to build them from a single source? [21:23] they seem related [21:23] ah, ok [21:23] pitti: they don't have to be [21:24] I can write a scope for the Music lens right now [21:24] so if the scope ceases to exist, they would just not display data any more [21:24] the Music lens in in Vala, my scope can be in Python [21:24] pitti: correct [21:24] soren: the ARB doesn't maintain the packages, the individual developers do, allowing dependencies would force the ARB to do actual maintenance of these packages [21:24] so wouldn't it be sufficient for the lens to Recommends: the scope and not depends on it? [21:24] stgraber, you're suggesting that if I write a useful scope for an existing lens -- say, I write a music scope that searches my favourite music provider, or my Sonos box, or something -- that I shouldn't be allowed to submit it? I should have to go to the music lens maintainer and beg them to include it (and leave them, officially, on the hook as the maintainer of it?) [21:24] if it can pull from several scopes? [21:24] stgraber, why? [21:24] pitti: other way, the scope currently depends on the lens [21:25] soren: instead I'd much prefer the lens develoepr to aggregate the different scopes for their lens and upload the bundle as a single source, ensuring they are all well tested together and offering us a single point of contact [21:25] stgraber, why should the lens dev be required to care about scopes he/she is uninterested in? [21:25] ^ that was my question, building them from the same source [21:25] stgraber: that will severely limit the number of independent scopes being written [21:26] I'll be honest and admit that this whole concept of lenses and scopes is new and mysterious to me, but it sounds to me like there's not a 1-to-1 relationship between them, nor even a 1-to-many, but rather a many-to-many? [21:26] pitti: the Unity API was specifically designed to allow their independent development and deployment [21:26] but how much sense does it make to write a scope (a data provider) without a lens (the presentation for it)? [21:26] mhall119: does the lens developer currently have to modify their package to support a new scope? [21:26] mhall119: (outside of Extras, I mean) [21:26] aquarius: if you write a scope for a lens that's in the archive, you can submit it to extras. If you write a scope for a lens that's in extras, you need to go through the developer of the lens [21:26] soren: it's one to many, a scope can really only target a single lens [21:26] if a lens depends on a scope, or the other way round, they already need to be developed and tested togeher, no? [21:26] wendar: no, lens authors don't need to do anything for scopes [21:26] stgraber, doesn't that put an inordinate burden on a lens developer? I'm not sure a lens developer should be required to test and verify scopes that they might not even be able to run (think of a video scope for a Canadian video provider, which can't be tested by a UK video lens developer). [21:26] and if they are really are so independent, why do they need to strictly depend on each other? [21:26] mhall119: Ok. [21:26] mhall119: Thanks. [21:27] pitti: no, there is no need for scopes and lenses to be developed and tested together [21:27] a scope author will need to know about the lens, but not the other way around [21:27] mhall119: so why do they need to Depends: to them then? [21:27] mhall119: so, the best analgogy for a scope, might be like an independent extension for an app? [21:27] a scope is useless without the lens it is written for [21:27] wendar: yes [21:27] wendar, agreed [21:27] mhall119: like, an ubuntuone extension for rhythmbox? [21:27] or the flash plugin for Mozilla [21:28] stgraber, I'm just picking music and video as obvious examples; if those being in the archive confuses matters, then I can talk about an ebooks lens, for example. Think of the author of the ebooks lens being, in your model, responsible for scopes for e-book stores which they can't even access for geographical reasons. [21:28] so we need to allow scopes to depend on the lens, but the lens does not need to depend on any scopes [21:28] aquarius: sure, and hopefully this extra burden will make them submit the lens to the archive where the Ubuntu development team will make sure it doesn't explode post-release making extending it with scopes in extras perfectly safe [21:28] stgraber: I can't concieve of any way, given the Unity API, that a lens can make a scope explode, or vice versa [21:29] stgraber: well, you can't (easily) introduce new software into stable ubuntu other than extras or backports [21:29] technically we can submit scopes to the ARB that don't depend on their lens [21:29] the current way the ARB works is "if it breaks we'll remove it", the ARB is not supposed to fix broken packages. This becomes problematic when we allow dependencies because then we might end up having to pull 10 packages because of one being broken, then deal with people complaining about it [21:29] stgraber, why would the ARB need to fix broken packages? [21:29] that's why I ask why a Recommends: would not suffice [21:29] as it wouldn't render packages uninstallable when the recommends get removed [21:30] stgraber: if you remove a broken scope, it won't break the lens, and if you remove a broken lens, the scope will just not be accessible [21:30] and the lenses woudl just display whatever data source is available [21:30] pitti: agreed, that's why I think the new cool lens should go to extras bundling some scopes initially, then for the next release, the lens should be in the archive and these scopes can then go as separate packages either in the archive or in extras [21:30] pitti: a scope depends on a lens and there are usually multiple scopes for a lens [21:30] pitti: the lense needs to be there for the scopes to be useful at all, so if the lense is in extras & then removed, the scopes won't be functional [21:31] pitti: so if we pull a lens, we have to pull all the scopes [21:31] stgraber, why? [21:31] stgraber: you don't [21:31] they just become inaccessible [21:31] and this is arguably what ratings and reviews are there to help with [21:31] mhall119: well, unless you want to end up with a bunch of useless packages, because without the lens, they are completely useless and so should be pulled or they'll confuse the users [21:32] stgraber: hence the reason we want a Depends in the scope package [21:32] stgraber: How will it be more or less confusing than the situation where it's all in the same package? [21:32] we can also remove all the rdepends [21:32] but I thought lenses could also show data from different scopes [21:32] stgraber: what would the downside be of having ScopeA depend on LensB? [21:32] so if you pull one scope, it wouldn't be useless [21:33] pitti: correct [21:33] pitti: I think the problem is more about if the lense gets pulled, breaking >1 scope [21:33] the reason for the Depends is so that you won't have a scope installed without the lens that is a capable of displaying it's results [21:33] soren: all in the same package means that we have a single point of contact and a single person updating them all, so it's unlikely that this person would break anything in an update to the lens because we can easily ensure the changes have been done for all the scopes === Guest65979 is now known as albrigha [21:33] soren: also, if we pull that source package, all the binaries come with it, without any extra work [21:33] ajmitch: if the lens gets pulled, it's scopes should be pulled, because they become useless [21:33] stgraber, I think you are thinking of Extras in the same way as we think of Main/Universe [21:34] mhall119: yeah, that's what we were saying :) [21:34] the point of Extras is to ease app devs getting their content in...requiring a maintainer for a collection of scopes and a lens is unrealistic [21:34] apart from anything, the Lens author may not care about the many scopes [21:34] stgraber: None of those arguments seem to have anything to do with confusion for users. [21:34] in the same way, the author of an app probably doesn't care about all of the plugins for his/her app [21:34] stgraber: Not saying they're invalid, just trying to understand the problem one aspect at a time. :) [21:35] the say that we should expect either a maintainer for the scopes and lens in Extras or for it to go into Main/Universe is going to affect the ability of our app devs to get their content into the Software Center [21:35] and as mhall119 said, the Lens/Scopes system was designed to be pluggable like this... [21:36] it's encouraged, in fact [21:36] soren: for the users, whether we pull a single source building all the binaries or all the sources, there won't be any difference. If we only take out the lens though, then they'll end up seeing 20 packages that when installed will do absolutely nothing [21:36] so, I still don't understand the fundamental problem here [21:36] either scopes and lenses _are_ coupled together by expected data format etc. and thus need to be written together [21:36] then removing one should also remove the other [21:37] pitti: only in one direction [21:37] or they are magically independently, then a recommends: would be more than enough? [21:37] stgraber: How do removals work, btw? [21:37] pitti: would a recommends: force the installation of a lens if I apt-get install a scope? [21:37] more like Enhances: [21:37] pitti: a scope depends on a lens. A lens can have multiple scopes. [21:37] stgraber: Do we replace the source package with one that builds empty binaries? [21:37] soren: upload of an empty package [21:37] s/binaries/binary ones/ [21:37] mhall119: right; if it was in two directions, there would be no doubt about putting them in one source or even one binary [21:38] stgraber: That won't remove the binary packages from users's systems. [21:38] I guess "empty binary" [21:38] doesn't software centre install recommends: packages by default? [21:38] soren: correct, in the case of a multi-binary package, we'd probably upload the main binary package as empty and conflict/break against all the others [21:38] yes, apt does [21:38] but it doesn't break if the recommends: doesn't exist [21:38] stgraber: Ok. [21:39] does removing a package (in USC or apt) remove any package that recommends it? [21:39] soren: so far we've been fortunate enough not to have to do anything like that though, so it's just the on-paper procedure ;) [21:39] mhall119: No. [21:39] so if we pull a scope, there is no problem [21:39] soren: then removing a lens package would leave useless scope packages installed if we only used Recommends [21:39] if we pull a lens, we either would drop the corresponding scopes as well, or just leave them if another lens uses them as well [21:39] ^ does that make sense? [21:39] mhall119: Not immediately, at least. It might be up for auto-removal later on, though. [21:40] pitti: you can't have multiple lenses use the same scope, the API doesn't allow that [21:40] ah, that makes it even easier then [21:40] mhall119, multiple installed lenses, right? [21:41] so dropping a lens would just mean to drop all dependent scopes as well [21:41] a scope is installed into a lens' directory in /usr/share/unity/lenses// [21:41] pitti: should drop them all, yes [21:41] right [21:42] so if we extended the policy so that removing a package would automatically drop all reverse dependencies, would there still be a maintenance/consistency problem? [21:42] we also have the issue where then two different source packages will be writting to the same path (as mhall119 pointed out that scopes are installed in the lens directory), looking for problems is pretty easy for the ARB when coming from the same source (just build the source, check all files in debian/, done), but can be much trickier to spot when in multiple sources [21:42] we still should not generally allow this [21:43] this situation alreayd stretches the idea of extras.u.c. to the max [21:43] stgraber: you have that already [21:43] and extras.u.c. should never be allowed to grow complex dependency trees [21:43] mhall119: no [21:43] stgraber: I can write two independent source packages that both try to install to the same /usr/share/unity/ [21:44] mhall119: we currently either build from the same source, making the check for such issues trivial or we install in an existing lens from the main archive, but then you have to prefix with extras- per policy, avoiding any potential clash [21:44] err, do we allow this? [21:44] I thought they'd need to use /opt/extras.u.c./project/ ? [21:44] There's an exception for these things. [21:44] ah, I think we had an exception for that, /me checks logs [21:44] pitti: they do, except for /usr/share/unity/ as we alloewd it a few meetings ago [21:44] pitti: for Unity we need to install .lens and .scope files into /usr/share/unity/lenses/ [21:44] yes, I remember [21:45] pitti: but we allowed it by enforcing a extras- prefix [21:45] and .service files need to be installed into /usr/share/dbus-1/ [21:45] pitti: which prefix becomes useless when allowing multiple packages in extras to write to the same path [21:45] but anyway, the ARB would hopefully reject a package foo if it installs a unity/extras-bar [21:45] it should be extras- and nothing else [21:46] pitti: for Unity lenses and scopes, we have to install some descriptive files into /usr/share [21:46] so, if the ARB is willing to remove reverse dependencies as well, I think the exception can be granted (although it's a very ugly precedent) [21:46] binaries and supporting code will live in /op/ [21:46] /opt/ [21:46] if not, then recommends: seems like a good enough compromise to me? [21:47] from a user experience perspective with recommends, if a user installs a scope, it won't pull in the lens, right? [21:47] it will, unless they change the default Apt settings [21:47] right [21:47] recommends are installed/upgraded by default [21:47] it's removal that Recommends will give a less than ideal experience [21:47] except that apt doesn't fall over if they don't exist [21:48] right [21:48] (and some technical details which don't matter here) [21:48] it's actually another issue I have with the proposal, no offence but it comes from the Canonical Community team without AFAICS any backing from the ARB (only e-mail from an ARB member I can see is mine and as you noticed, I'm against it) [21:48] so if the user removes the lens, some scopes will by laying around [21:48] stgraber, does it matter who raises this topic? [21:48] pitti: oh, so then if stgraber pulls a lens package from extras, a user can still install one of it's scope packages without being told it won't work? [21:48] also, we discussed with the ARB first and were told to bring it to the TB [21:48] jono: that's no different with Depends:; that's the job of autoremove [21:48] pitti, gotcha [21:48] stgraber: I'm also generally against it, but the redeeming feature from my perspective is that mhall119 will be doing most of the work [21:49] stgraber: both you and highvoltage encouraged me to raise this with the TB [21:49] against it from the same perspective as pitti: it's kind of ugly [21:49] well, more important than "ugly" is that it imposes extra responsibility on the ARB team [21:50] if they are willing to check for reverse dependencies on removal, it seems okay [21:50] what exactly are the extra responsibilities? [21:50] sorry, I'm unclear on what work will be required [21:50] if mhall119 is willing to participate as an app-review-contributor, and watch over the scopes and lenses, it's less of a stress on the ARB [21:50] introducing the concept of dependencies (in essence, a parallel distro) [21:50] mhall119: that's correct because we were definitely stuck and only the TB can do the policy change, I just mean that we should vote on "allowing the ARB to" not "the ARB needs to" and then let the ARB choose whether to go with it or not depending on the estimated extra work [21:50] * ajmitch isn't against it as such, mostly because of it being somewhat useful & not being directly against the extension repository policy [21:51] with all the fun that potentially comes with it (circular depends, NBS transitions, uninstallable packages, nontrivial removals) [21:51] pitti: is that a reasonable concern if it's only for lenses and scopes? [21:51] removals *ought* to be rare, I hope [21:51] stgraber, I don't understand, if you wanted to discuss this, why didn't you raise this when we brought it to the ARB? [21:51] yes, as the ARB will need to carry that ^, I'm all for letting the ARB decide this [21:51] I guess the practical question for me, which we'll only see over time, is how much demand there is for releasing new lenses on the "current" release [21:51] as opposed to requesting TB discussion [21:51] mhall119: you know how it is with precedents :) [21:52] mhall119: this will quickly turn into a parallel distro [21:52] jono: we definitely needed TB guidance on whether an exception was even possible [21:52] pitti: yes, but we shouldn't avoid making good progress for fear of possible slippery-slopes somewhere down the road [21:52] as next week someone will have a very good argument why they will need to put their library package into extras [21:52] wendar, agreed [21:52] jono: if they say "No", then the ARB doesn't even need to discuss it [21:52] jono: I was actually hoping for someone else on the ARB to say something, didn't quite happen though ;) TB approval would be needed regardless, so adding it to the TB agenda would have been the right thing to do in all cases [21:52] pitti, wouldn't this be an exemption though, just for scopes/lenses? [21:52] wendar: exactly [21:52] jono: if they say yes, then a deeper discussion of the potential risks, how to mitigate them, etc. is in order [21:53] mhall119: I don't think it's unreasonable extra effort, but as I said, as it's the ARB which will need to do the work [21:53] stgraber: sorry, I was waiting for the TB meeting :) [21:53] jono: we can certianly make the wording pretty tight for that, yes [21:53] I think it is fair that the ARB provides input on this [21:54] but my worry is that if the ARB is not interesting in this, that this will be a singificant blocker for getting all these fantastic scopes/lenses into the USC [21:54] mhall119: yep, I told you to raise it with the TB (as apposed to you and jono trying to bully people to submitting to your ideas on #ubuntu-arb) [21:54] if the TB/ARB made an exception, it should be clear that it's *only* for lenses/scopes [21:54]