=== 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
araOK, we should get started16:01
meetingologyMeeting started Mon Feb 20 16:01:21 2012 UTC.  The chair is ara. Information about MeetBot at http://wiki.ubuntu.com/meetingology.16:01
meetingologyAvailable 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 #votesrequired16:01
arawelcome to the Ubuntu Friendly meeting #3416:01
ara#topic Optical drive testing for Ubuntu Friendly (roadmr)16:01
=== meetingology changed the topic of #ubuntu-meeting to: Optical drive testing for Ubuntu Friendly (roadmr)
roadmrhi all!16:02
roadmrThe situation is as follows. We now have a very nice automated CD writing test16:02
roadmrwhat it does is, it asks for blank media, writes some files to it, and then tries to read them16:03
roadmrthis enables us to test reading and writing with just one test, thus being quicker for the user16:03
roadmrthe problem is, the way the test was designed, it would be the *only* CD test run16:03
roadmrand the consequence for Ubuntu Friendly is that, if the drive supports writing, this test will ask the user for blank media16:03
roadmrif the user has no blank media, the test will either fail or be skipped16:04
roadmrand 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 disk16:04
roadmrSo 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:04
roadmrWe'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/additional16:05
roadmranother possibility would be to rework this test so it behaves differently16:06
roadmrand 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
roadmrSo that's the situation. Ideas anyone?16:06
roadmrara, you're first16:07
araso, basically, we have three (and not two) types of tests: optional, core and skippable core16:07
araI think we need to keep 2 tests16:07
arathe read one to be core, and the write one to be skippable16:07
arato have only one for Ubuntu Friendly is not the answer16:08
araas many people would skip the write one16:08
araand in the end no one would be testing even the reading capabilities16:08
roadmrOK, yes, the original proposal was to skip the read-only test entirely if the write one was runnable16:09
roadmrbrendand: your turn16:09
brendandsimilar to what ara said16:09
brendandit's fairly straightforward,16:09
brendandany test which has a valid reason why it could not be run should be skippable16:10
brendandi 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
arabrendand, agree16:11
arabrendand, I stand corrected, both should be skippable16:11
roadmrjedimike, could you remind us how the optical tests are considered right now? are they core-core or core-skippable? :)16:12
brendandi 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 skippable16:12
jedimikeroadmr: let me check...16:12
brendandfor optical media i think a penalty is enough16:12
brendanda further conundrum is if the drive doesn't have a write capability then it will be penalised16:14
brendandeven though it could never be expected to support that capability16:14
brendandhow to deal with that?16:14
jedimikeoptical 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:15
roadmrjedimike: 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
jedimikeroadmr: ok, the category mappings still need to be copied across though, I'll get on to that.16:16
araroadmr, jedimike: I think we need an action item to coordinate and fix the mappings for 12.0416:17
jedimikeara: 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:17
roadmrara: also the whitelist could potentially still change, so I'd say not to set the mappings "in stone" until later16:18
araagree, but we need to start selecting the skippable16:19
arato start gathering data on staging16:19
araand be able to fix stuff16:19
roadmrara: 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 data16:19
roadmrara: agreed, so the most pressing thing would be to look at the current whitelist and see how the tests are classified16:20
roadmranyone want to work with jedimike on this? :)16:20
roadmr(I can do it)16:20
roadmr[ACTION] jedimike and roadmr to review the current default checkbox whitelist to ensure core-core/core-skippable/skippable-skippable mappings still make sense16:21
meetingologyACTION: jedimike and roadmr to review the current default checkbox whitelist to ensure core-core/core-skippable/skippable-skippable mappings still make sense16:21
roadmr[ACTION] bladernr, roadmr and spineau to decide whether it makes sense to put the optical/write test back without removing the read one, so that functionality gets at least tested (will penalize if the user decides to skip)16:22
meetingologyACTION: 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
roadmranything else needed on this topic?16:22
araOK, let's move on!16:24
ara#topic "The Eagle has landed" - Checkbox-qt now available in Precise, call for testing (roadmr)16:24
=== meetingology changed the topic of #ubuntu-meeting to: "The Eagle has landed" - Checkbox-qt now available in Precise, call for testing (roadmr)
araroadmr, all yours (again)16:24
roadmrheheh :) I blame bladernr16:24
roadmranyway - so yes, the new and shiny checkbox-qt interface for Checkbox has landed in Ubuntu.16:24
roadmrAs 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
roadmrTo use it, just apt-get install checkbox-qt16:25
roadmrand run checkbox-qt instead of checkbox-gtk16:25
roadmrSo please test and either send your comments to the mailing list or file Launchpad bugs for the stuff that bugs you!16:26
roadmrcr3: go ahead!16:26
cr3just to announce that we're still in the process of getting checkbox-qt on the desktop image but there's no significant blockers so far16:26
roadmrcr3: awesome, thanks! yes, for now it requires manual installation but the package is tiny so the pain should be minimal16:26
roadmrthat's all really on this topic :)16:28
araOK, any other questions or comments on the topic?16:28
ara#topic AOB16:29
=== meetingology changed the topic of #ubuntu-meeting to: AOB
araAnybody else has any other topics to talk about?16:29
arawithout the else, of course16:29
araif roadmr has other topics he's more than welcome to share them :)16:29
* roadmr has nothing else :(16:29
aragoing once...16:30
aragoing twice...16:30
=== 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
meetingologyMeeting ended Mon Feb 20 16:30:42 2012 UTC.16:30
meetingologyMinutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-20-16.01.moin.txt16:30
meetingologyMinutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-20-16.01.html16:30
arathanks all!16:30
roadmrthanks! bye!16:33
=== JackyAlcine_ is now known as JackyAlcine
=== Quintasan_ is now known as Quintasan
=== allison_ is now known as wendar
pittikees: can you chair today? cjwatson is off for enlarging his family :)20:54
pittiand you'd be next alphabetically I think20:54
jonois the TB meeting now?21:00
sorenjono: Yup.21:00
sorenWell, or supposed to be, at least.21:00
jonohey soren, hows things?21:00
* stgraber waves21:00
jonohowdy stgraber21:01
* mhall119 waves21:01
sorenjono: Gosh. Good question :)21:01
sorenjono: Nah, it's all good, I guess. Just almost too busy to stop and realise it.21:02
sorenjono: So thanks for forcing me to :)21:02
jonoindeed :-)21:02
pittihey soren21:02
sorenpitti: o/21:02
pittistgraber: there?21:02
sorenpitti: Did you ping anyone else besides kees?21:02
stgraberpitti: yep21:03
pittisoren: not yet21:03
pittipinged mdz now21:03
pittimhall119: are you there to discuss your topic?21:05
pittiseems to be our only topic today anyway21:05
mhall119pitti: yes21:05
pittiI didn't scan the ML thoroughly, though, I just returned back home (was on vac today)21:06
jonodo we know if sabdfl can make it?21:07
pittijono: he's not a regular member of TB any more, so only attending some meetings21:08
pittiso, seems kees is off as well21:08
pittiand I'm next on the list, so21:08
meetingologyMeeting started Mon Feb 20 21:08:58 2012 UTC.  The chair is pitti. Information about MeetBot at http://wiki.ubuntu.com/meetingology.21:08
meetingologyAvailable 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 #votesrequired21:08
pitti#topic action review21:09
=== meetingology changed the topic of #ubuntu-meeting to: action review
pittikees to perform brainstorm review21:09
pittiI think we can safely drop this one now, as the next one is due in March21:09
pittiLaney and wendar to get trademark policy updated wrt remixes21:09
pitti^ do you happen to be online?21:09
wendarpitti: we've submitted a ticket for it21:09
wendarjust a sec, will look for the ticket #21:10
pittiwendar: thanks21:10
pittiso, sounds like "in progress"21:10
wendaralso, we had a suggestion about adding some information to the extension repository policy21:10
wendar"If the software does not allow redistribution, document this clearly in the debian/copyright file."21:11
wendarwith supporting documentation suggesting to add this as a comment in DEP5 format21:11
pittiI guess remixes need to carefully go through the licenses of partner anyway21:11
wendarwe talked some with SPDX about whether they had any standard way of tagging non-redistributable software21:11
wendarand, they said no21:11
wendarsome standard comment seemed helpful21:12
sorenSorry, "SPDX"?21:12
wendarsoren: that's the group that's working on license metadata21:12
wendarlike DEP5, but more general21:12
sorenWhat's it short for?21:13
wendarskaet is one of the leaders of the group21:13
wendar"Software Package Data Exchange"21:13
sorenCool. Thanks.21:13
wendarjust a side conversation to see if we could standardize on prior art21:13
wendarthe main idea is just to provide reasonable notification to the consumers of the packages21:13
wendarand, 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 remix21:14
wendarBut,  no need to go into specific implementation details in the ExtensionRepositoryPolicy21:15
wendarWould you all be comfortable adding "If the software does not allow redistribution, document this clearly in the debian/copyright file."21:15
wendarto the current policy?21:15
wendarunder 2.3 "Copyright Considerations"21:15
wendar(no rush, can be considered and held over to the next meeting)21:16
pittiactually this is alreayd the point of the copyright file21:16
pittibut pointing it out more explicitly/machine readable sounds fine and straightforward21:16
sorenYeah, I have no problem with that.21:16
ubottuError: launchpad bug 933187 not found21:16
pittinice, fix committed already21:17
pittiwendar: thanks for the update!21:17
pitti#topic Can an ARB exception be made allowing Scopes packages to depend on Lens packages in extras - mhall11921:17
=== 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
pittiah, right, right now extras pacakges can only depend on Ubuntu packages, not to each other, right?21:18
mhall119pitti: right, the current policy is that one package in extras can't depend on another in extra21:18
pittiI see how that might be required for libraries, but what was the general reason for this?21:18
mhall119but the Unity API encourages separate development of lenses and scopes21:18
mhall119tl;dr, it makes it harder to remove problem packages from extras if other packages in extras might depend on them21:20
wendarnote that in the general ExtensionRepositoryPolicy, packages in Extras can depend on other packages in Extras21:20
stgraber(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
wendar(this is because it's generic for all)21:20
wendarbut, Extras specifically doesn't permit libraries21:20
mhall119If not a general rule change, I would like to at least get a specific exception for the case of lenses and scopes21:20
wendarindependent libraries21:20
mhall119I have a list of 61 lenses and scopes being developed21:21
mhall119so far only 6 have gone through the ARB process21:21
jonomy 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 ARB21:21
mhall11929 of those are scopes that live independently from the lens they extend21:21
jonoand 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 process21:21
ajmitcha lense isn't exactly a library, it's more an app for which the scopes are plugins21:22
mhall119ajmitch: except that the Unity API allows the scope to run in a separate, independent process21:22
mhall119and community over dbus21:22
pittiso if we'd pull a scope from extras, what would the lenses do?21:22
pittiAFAICS we'd need to remove them from extras as well, right?21:23
ajmitchmhall119: right, plugin in the data sense rather than sharing the same process21:23
mhall119pitti: the lens tells the Dash how to display results from the scope21:23
sorenstgraber: So you'd prefer that people lump them together in a single binary package?21:23
stgrabersoren: into a single source package. Multiple binary from a single source is already allowed in extras21:23
mhall119pitti: one lens can have multiple, independent scopes, that provide it with data to display in the dash21:23
pittimhall119: would it not make sense to build them from a single source?21:23
pittithey seem related21:23
pittiah, ok21:23
mhall119pitti: they don't have to be21:23
mhall119I can write a scope for the Music lens right now21:24
pittiso if the scope ceases to exist, they would just not display data any more21:24
mhall119the Music lens in in Vala, my scope can be in Python21:24
mhall119pitti: correct21:24
stgrabersoren: the ARB doesn't maintain the packages, the individual developers do, allowing dependencies would force the ARB to do actual maintenance of these packages21:24
pittiso wouldn't it be sufficient for the lens to Recommends: the scope and not depends on it?21:24
aquariusstgraber, 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
pittiif it can pull from several scopes?21:24
jonostgraber, why?21:24
mhall119pitti: other way, the scope currently depends on the lens21:24
stgrabersoren: 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 contact21:25
jonostgraber, why should the lens dev be required to care about scopes he/she is uninterested in?21:25
pitti^ that was my question, building them from the same source21:25
mhall119stgraber: that will severely limit the number of independent scopes being written21:25
sorenI'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
mhall119pitti: the Unity API was specifically designed to allow their independent development and deployment21:26
pittibut how much sense does it make to write a scope (a data provider) without a lens (the presentation for it)?21:26
wendarmhall119: does the lens developer currently have to modify their package to support a new scope?21:26
wendarmhall119: (outside of Extras,  I mean)21:26
stgraberaquarius: 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 lens21:26
mhall119soren: it's one to many, a scope can really only target a single lens21:26
pittiif a lens depends on a scope, or the other way round, they already need to be developed and tested togeher, no?21:26
mhall119wendar: no, lens authors don't need to do anything for scopes21:26
aquariusstgraber, 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
pittiand if they are really are so independent, why do they need to strictly depend on each other?21:26
sorenmhall119: Ok.21:26
sorenmhall119: Thanks.21:26
mhall119pitti: no, there is no need for scopes and lenses to be developed and tested together21:27
mhall119a scope author will need to know about the lens, but not the other way around21:27
pittimhall119: so why do they need to Depends: to them then?21:27
wendarmhall119: so, the best analgogy for a scope, might be like an independent extension for an app?21:27
mhall119a scope is useless without the lens it is written for21:27
mhall119wendar: yes21:27
jonowendar, agreed21:27
wendarmhall119: like, an ubuntuone extension for rhythmbox?21:27
mhall119or the flash plugin for Mozilla21:27
aquariusstgraber, 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
jonoso we need to allow scopes to depend on the lens, but the lens does not need to depend on any scopes21:28
stgraberaquarius: 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 safe21:28
mhall119stgraber: I can't concieve of any way, given the Unity API, that a lens can make a scope explode, or vice versa21:28
pittistgraber: well, you can't (easily) introduce new software into stable ubuntu other than extras or backports21:29
mhall119technically we can submit scopes to the ARB that don't depend on their lens21:29
stgraberthe 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 it21:29
jonostgraber, why would the ARB need to fix broken packages?21:29
pittithat's why I ask why a Recommends: would not suffice21:29
pittias it wouldn't render packages uninstallable when the recommends get removed21:29
mhall119stgraber: 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 accessible21:30
pittiand the lenses woudl just display whatever data source is available21:30
stgraberpitti: 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 extras21:30
stgraberpitti: a scope depends on a lens and there are usually multiple scopes for a lens21:30
ajmitchpitti: 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 functional21:30
stgraberpitti: so if we pull a lens, we have to pull all the scopes21:31
jonostgraber, why?21:31
mhall119stgraber: you don't21:31
mhall119they just become inaccessible21:31
jonoand this is arguably what ratings and reviews are there to help with21:31
stgrabermhall119: 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 users21:31
mhall119stgraber: hence the reason we want a Depends in the scope package21:32
sorenstgraber: How will it be more or less confusing than the situation where it's all in the same package?21:32
pittiwe can also remove all the rdepends21:32
pittibut I thought lenses could also show data from different scopes21:32
mhall119stgraber: what would the downside be of having ScopeA depend on LensB?21:32
pittiso if you pull one scope, it wouldn't be useless21:32
mhall119pitti: correct21:33
ajmitchpitti: I think the problem is more about if the lense gets pulled, breaking >1 scope21:33
mhall119the 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 results21:33
stgrabersoren: 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 scopes21:33
=== Guest65979 is now known as albrigha
stgrabersoren: also, if we pull that source package, all the binaries come with it, without any extra work21:33
mhall119ajmitch: if the lens gets pulled, it's scopes should be pulled, because they become useless21:33
jonostgraber, I think you are thinking of Extras in the same way as we think of Main/Universe21:33
ajmitchmhall119: yeah, that's what we were saying :)21:34
jonothe point of Extras is to ease app devs getting their content in...requiring a maintainer for a collection of scopes and a lens is unrealistic21:34
jonoapart from anything, the Lens author may not care about the many scopes21:34
sorenstgraber: None of those arguments seem to have anything to do with confusion for users.21:34
jonoin the same way, the author of an app probably doesn't care about all of the plugins for his/her app21:34
sorenstgraber: Not saying they're invalid, just trying to understand the problem one aspect at a time. :)21:34
jonothe 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 Center21:35
jonoand as mhall119 said, the Lens/Scopes system was designed to be pluggable like this...21:35
mhall119it's encouraged, in fact21:36
stgrabersoren: 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 nothing21:36
pittiso, I still don't understand the fundamental problem here21:36
pittieither scopes and lenses _are_ coupled together by expected data format etc. and thus need to be written together21:36
pittithen removing one should also remove the other21:36
mhall119pitti: only in one direction21:37
pittior they are magically independently, then a recommends: would be more than enough?21:37
sorenstgraber: How do removals work, btw?21:37
mhall119pitti: would a recommends: force the installation of a lens if I apt-get install a scope?21:37
ajmitchmore like Enhances:21:37
stgraberpitti: a scope depends on a lens. A lens can have multiple scopes.21:37
sorenstgraber: Do we replace the source package with one that builds empty binaries?21:37
stgrabersoren: upload of an empty package21:37
sorens/binaries/binary ones/21:37
pittimhall119: right; if it was in two directions, there would be no doubt about putting them in one source or even one binary21:37
sorenstgraber: That won't remove the binary packages from users's systems.21:38
pittiI guess "empty binary"21:38
aquariusdoesn't software centre install recommends: packages by default?21:38
stgrabersoren: 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 others21:38
pittiyes, apt does21:38
pittibut it doesn't break if the recommends: doesn't exist21:38
sorenstgraber: Ok.21:38
mhall119does removing a package (in USC or apt) remove any package that recommends it?21:39
stgrabersoren: 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
sorenmhall119: No.21:39
pittiso if we pull a scope, there is no problem21:39
mhall119soren:  then removing a lens package would leave useless scope packages installed if we only used Recommends21:39
pittiif we pull a lens, we either would drop the corresponding scopes as well, or just leave them if another lens uses them as well21:39
pitti^ does that make sense?21:39
sorenmhall119: Not immediately, at least. It might be up for auto-removal later on, though.21:39
mhall119pitti: you can't have multiple lenses use the same scope, the API doesn't allow that21:40
pittiah, that makes it even easier then21:40
jonomhall119, multiple installed lenses, right?21:40
pittiso dropping a lens would just mean to drop all dependent scopes as well21:41
mhall119a scope is installed into a lens' directory in /usr/share/unity/lenses/<lens_name>/21:41
mhall119pitti: should drop them all, yes21:41
pittiso 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
stgraberwe 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 sources21:42
pittiwe still should not generally allow this21:42
pittithis situation alreayd stretches the idea of extras.u.c. to the max21:43
mhall119stgraber: you have that already21:43
pittiand extras.u.c. should never be allowed to grow complex dependency trees21:43
stgrabermhall119: no21:43
mhall119stgraber: I can write two independent source packages that both try to install to the same /usr/share/unity/<lens_name>21:43
stgrabermhall119: 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 clash21:44
pittierr, do we allow this?21:44
pittiI thought they'd need to use /opt/extras.u.c./project/ ?21:44
sorenThere's an exception for these things.21:44
pittiah, I think we had an exception for that, /me checks logs21:44
stgraberpitti: they do, except for /usr/share/unity/<lens name> as we alloewd it a few meetings ago21:44
mhall119pitti: for Unity we need to install .lens and .scope files into /usr/share/unity/lenses/21:44
pittiyes, I remember21:44
stgraberpitti: but we allowed it by enforcing a extras- prefix21:45
mhall119and .service files need to be installed into /usr/share/dbus-1/21:45
stgraberpitti: which prefix becomes useless when allowing multiple packages in extras to write to the same path21:45
pittibut anyway, the ARB would hopefully reject a package foo if it installs a unity/extras-bar21:45
pittiit should be extras-<packagename> and nothing else21:45
mhall119pitti: for Unity lenses and scopes, we have to install some descriptive files into /usr/share21:46
pittiso, 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
mhall119binaries and supporting code will live in /op/21:46
pittiif not, then recommends: seems like a good enough compromise to me?21:46
jonofrom a user experience perspective with recommends, if a user installs a scope, it won't pull in the lens, right?21:47
mhall119it will, unless they change the default Apt settings21:47
pittirecommends are installed/upgraded by default21:47
mhall119it's removal that Recommends will give a less than ideal experience21:47
pittiexcept that apt doesn't fall over if they don't exist21:47
pitti(and some technical details which don't matter here)21:48
stgraberit'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
jonoso if the user removes the lens, some scopes will by laying around21:48
jonostgraber, does it matter who raises this topic?21:48
mhall119pitti: 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
jonoalso, we discussed with the ARB first and were told to bring it to the TB21:48
pittijono: that's no different with Depends:; that's the job of autoremove21:48
jonopitti, gotcha21:48
wendarstgraber: I'm also generally against it, but the redeeming feature from my perspective is that mhall119 will be doing most of the work21:48
mhall119stgraber: both you and highvoltage encouraged me to raise this with the TB21:49
wendaragainst it from the same perspective as pitti: it's kind of ugly21:49
pittiwell, more important than "ugly" is that it imposes extra responsibility on the ARB team21:49
pittiif they are willing to check for reverse dependencies on removal, it seems okay21:50
mhall119what exactly are the extra responsibilities?21:50
mhall119sorry, I'm unclear on what work will be required21:50
wendarif 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 ARB21:50
pittiintroducing the concept of dependencies (in essence, a parallel distro)21:50
stgrabermhall119: 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 work21:50
* ajmitch isn't against it as such, mostly because of it being somewhat useful & not being directly against the extension repository policy21:50
pittiwith all the fun that potentially comes with it (circular depends, NBS transitions, uninstallable packages, nontrivial removals)21:51
mhall119pitti: is that a reasonable concern if it's only for lenses and scopes?21:51
ajmitchremovals *ought* to be rare, I hope21:51
jonostgraber, 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
pittiyes, as the ARB will need to carry that ^, I'm all for letting the ARB decide this21:51
wendarI 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" release21:51
jonoas opposed to requesting TB discussion21:51
pittimhall119: you know how it is with precedents :)21:51
pittimhall119: this will quickly turn into a parallel distro21:52
wendarjono: we definitely needed TB guidance on whether an exception was even possible21:52
mhall119pitti: yes, but we shouldn't avoid making good progress for fear of possible slippery-slopes somewhere down the road21:52
pittias next week someone will have a very good argument why they will need to put their library package into extras21:52
jonowendar, agreed21:52
wendarjono: if they say "No", then the ARB doesn't even need to discuss it21:52
stgraberjono: 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 cases21:52
jonopitti, wouldn't this be an exemption though, just for scopes/lenses?21:52
stgraberwendar: exactly21:52
wendarjono: if they say yes, then a deeper discussion of the potential risks, how to mitigate them, etc. is in order21:52
pittimhall119: I don't think it's unreasonable extra effort, but as I said, as it's the ARB which will need to do the work21:53
ajmitchstgraber: sorry, I was waiting for the TB meeting :)21:53
pittijono: we can certianly make the wording pretty tight for that, yes21:53
jonoI think it is fair that the ARB provides input on this21:53
jonobut 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 USC21:54
highvoltagemhall119: 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
wendarif the TB/ARB made an exception, it should be clear that it's *only* for lenses/scopes21:54
mhall119to be frank, I have 60+ packages and counting that I need to get packaging resolved for, and I won't want to wait until the week or two before release to get started21:54
jonohighvoltage, bully is a strong word21:54
pittijono: well, that's much different than discussing technical implementations of dependencies, though :)21:54
wendarnot for extensions/libraries in general21:54
highvoltagejono: perhaps, but it's exactly what it looked like to me.21:54
mhall119highvoltage: it was more desperate pleas for assistance21:55
jonopitti, agreed, but I would suggest that the app developer experience is what we are wanting to improve21:55
wendarand, to offer support for mhall119, FeatureFreeze is past, and the only way these are getting in to Ubuntu before October is through Extras21:55
jonobut agreed on the technical discussion here21:55
wendar(which is part of why Extras was created in the first place)21:55
sorenJust a comment on the process: I understand this is something the TB ultimately needs to approve for the ARB to be able to approve it, but I'd really prefer such requests to come from the ARB after discussion there.21:55
pittimhall119: well, I don't think this needs to block you; you can start with Recommends:, and upgrade to depends: later on if/when the exception gets granted and the ARB is comfortable with it21:55
wendarsoren: apologies, we were at an impasse21:56
mhall119pitti: I can, yes, but that's going to be extra work for me if I have to go back and re-do packaging if we don't have a firm decision today21:56
wendarI'm honestly 50/50 on this one, I see good and bad21:56
sorenI don't see why the ARB couldn't discuss it and offer a proposal to the TB for approval/rejection. IMO, the ARB should feel empowered to do so.21:56
wendarperhaps we could agree to approve it for Oneiric, and revisit for consideration in Precise?21:56
ajmitchwendar: I'm about the same21:56
mhall119at the rate we're getting new lenses/scopes, I don't be able to attend to all of them on my own21:57
micahgwendar: backports would still be an option possibly21:57
pittiso, I don't personally have a problem with adding this exception, but with my TB hat I'm not comfortable making this over teh ARB's head21:57
wendarmichahg: but, they wouldn't be in Precise, so fail the "accepted to one release" test21:57
sorenpitti: Yeah, I agree with that.21:57
wendarmicahg: backports could also make an exception, but that's another conversation21:58
* ScottK looks up21:58
jonomaybe the ARB can discuss and then present their views at the next TB meeting?21:58
sorenpitti: We could say "the TB grants the ARB permission to approve/reject this new policy", but that's really a backwards way to go about this.21:58
highvoltagemicahg: that sounds good, but is it technically feasable? backports isn't enabled by default, is it?21:58
micahghighvoltage: it is from oneiric on21:58
wendarpitti: perhaps the answer here is: the TB is open to making an exception, pending a recommendation from the ARB?21:58
highvoltagemicahg: ooh21:58
ajmitchhighvoltage: it is, but pre-release backports isn't enabled yet21:58
pittiwendar: that's pretty much my feeling, yes21:58
pittiand we have a working alternative right now21:59
ScottKBackports is for stuff in Ubuntu, not extras, so I'm really confused.21:59
pittiyes, backports has nothing to do with this really21:59
mhall119stgraber: wendar: what will be required from the ARB if we go with Recommends, and a user complains about installable scopes not working (because the lens was removed)?21:59
micahgwell, if stuff would never get in the distro then certainly not21:59
highvoltageok. I thought that if you could get dependencies backported, it could solve the lenses and scopes problem by having some scopes in backports22:00
pittimhall119: removing the scope as well, I guess22:00
ScottKhighvoltage: Need to get them into the distro first though.22:00
stgrabermhall119: manual removal of all these scopes by uploading an empty package as their source22:00
stgrabermhall119: the problem is removal done this way will still show up in the software cener22:00
wendarmhall119:  not sure really, we don't have a policy or process because we have no dependencies in the ARB now22:00
mhall119pitti: and will that be easier on the ARB than if we used Depends?22:00
stgrabermhall119: so people will probably still try to install them even though there are scary warnings everywhere saying the package is empty22:01
wendarmhall119: which is exactly what we need to figure out22:01
pittimhall119: using recommends: requires hat the recommending package fails gracefully if the recommended package is not there any more22:01
pittimhall119: so with recommends: we don't need a policy/workflow change22:01
pittimhall119: and I think with lenses/scopes that property should already be built into unity/the API, right?22:02
mhall119pitti: correct, but what I'm asking is whether or not that will actually make it easier for the ARB22:02
stgraberI don't think Recommends is a good idea to be honnest, I actually think it's worse than Depends ... because with Depends, your system will know it's broken, with Recommends, you'll just have useless packages with no way to know which and why22:02
pittimhall119: I think so, yes22:02
pittianyway, we are out of time22:02
mhall119pitti: stgraber disagrees :)22:02
stgraberusing Recommends is just playing on words to avoid the "packages can't depend on other extra packages"22:02
wendarwe'll plan a separate ARB meeting22:03
wendarand, bring back our recommendation to the next TB meeting22:03
ajmitchwendar: we have an ARB meeting this friday22:03
pittistgraber: well, if the idea of that clause was to avoid breaking packages when removing other packages, recommends: would provide exactly that22:03
pittii. e. you can remove a package without having to play a fully fledged archive admin process/check22:03
pittiwendar: yes, I think that'd be best22:04
wendarajmitch: I thought so, but didn't check the calendar yet22:04
stgraberpitti: right, won't prevent people installing them and wondering why they don't do anything though ;)22:04
stgraberpitti: so it's policy-compliant but really confusing for the users...22:04
pittistgraber: I see no difference with using Depends: there22:04
stgraberpitti: I agree, I'm against both22:04
pittistgraber: if you use empty packages, you'll have that problem either way22:04
mhall119stgraber: wendar: Just so I'm clear on this, if I start submitting scope packages that Recommends: an existing lens package in Extras, will that be allowed or not?22:04
wendarmhall119: it still fails on the "no libraries, only stand-alone applications" policy22:05
mhall119wendar: how?22:05
wendarmhall119: so, we'd still have to hold them until after the ARB meeting Friday22:05
wendarscopes aren't stand-alone applications22:05
wendarfor that matter, neither are lenses22:06
mhall119wendar: does that mean that Scopes will not be allowed at all, unless they are incorporated into the lens package?22:06
wendarbut, we're heading off into rabbit trails there22:06
wendarmhall119: I don't know yet22:06
wendarmhall119: can you join us on Friday?22:06
mhall119wendar: I have multiple developers waiting on my to get their packaging going, I need *something*22:06
wendarmhall119: the meeting schedule is on the Fridge22:06
mhall119yes, I will be there Friday22:06
pittiyes, this stretches the idea of what extras is to the max, as I already said earlier22:06
wendarmhall119: thanks!22:07
pittiso it'll be an extension of the "spirit" anyway22:07
stgrabermhall119: for now, you can always submit these that are simply scopes+lens bundled, for these that need to be in multiple packages, hold until we made a decision22:07
mhall119can we at least all agree that we want to allow lens and scope authors to be able to submit thir packages to extras in some fashion?22:07
wendarmhall119: don't want to inconvenience them, but it is worth talking this through22:07
pitti^ that's an ARB question, I think22:07
stgrabermhall119: I'm sure you already have some simple ones that are similar to these we already accepted (askubutu, ssh, utilities, calculator, city)22:08
wendarmhall119: it sounded like we had a workable fall-back plan that would allow them22:08
pittiit's not an "application" after alll, it's a plugin for your desktop22:08
mhall119stgraber: yes, but the conversation has shifted into questioning whether those should be allowed22:08
mhall119so if we can at the very least get consensus that these are an appropriate use of the extras repository, I'd feel much more comfortable22:09
stgrabermhall119: I think we want lenses/scopes in extras but we want them in a managable way. We already did the policy changes required to allow for a single source package to provide scopes and lenses and we already approved some of them22:09
mhall119thank you stgraber22:09
stgrabermhall119: so as long as your submissions are similar to what we already have in extras, I don't see any problem22:09
wendarstgraber: agreed22:09
stgrabermhall119: for anything that you wan to send as multiple source packages, please wait22:09
mhall119stgraber: I see a problem, but I suppose we can discuss that on Friday22:10
mhall119pitti: then can the TB officially allow the ARB to make a decision on this rule?22:10
pittiI'm fine with that22:10
stgrabermhall119: I think the plan is for the ARB to send the proposal to the next TB meeting based on the result of our meeting on Friday22:10
jonook so the decision is to defer to the ARB for discussion22:11
jonoand then the ARB to present their views to the TB for any further discussion22:11
mhall119stgraber: you're killing me here22:11
pittiwe can also vote on the ARB proposal on the mailing list22:11
stgrabereither voting on the ML or at next TB meeting works for me, if voting on the ML is better for mhall119, sure we can try that22:12
mhall119whatever gets a vote sooner is best for me22:12
stgraberbut that's a big enough policy change that I want the TB to explicitly vote on it, not just delegate to the ARB22:12
mhall119I have to answer to developers who want to make contributions that they currently aren't allowed to22:12
mhall119the longer I keep them waiting, the more of them we're going to lose22:13
jonoI think it seems fair to have the ARB discuss and present a view and then the TB to have an explicit voite22:13
sorenI have to wonder how we ended up in a situation where the TB needs to sign off on this.22:14
pittisoren: TB is responsible for https://wiki.ubuntu.com/ExtensionRepositoryPolicy22:14
sorenI would have expected the ARB to be able to make these decisions, and if they felt unfit to do so (or if someone else saw them unfit to do so), it could be raised to the TB.22:14
mhall119soren: the ARB felt that they didn't have the authority to make this decision22:15
sorenmhall119: That's fair enough.22:15
ajmitchsoren: it's not entirely clear what policy the ARB is allowed to decide - I think this one went to the TB because it changes the approved process22:16
pittiI see two questions for the ARB:22:16
pitti- do you consider lenses/scopes appropriate content for extras.u.c.22:16
pitti- would you be willing to do the extra effort of removing transitive dependencies when removing a package22:17
pittithe second is one that only the ARB can decide22:17
pittithe first one seems an appropriate question for both ARB and TB22:17
mhall119we can limit that second one to only a single level of dependency between only 2 very specific kinds of packages22:17
pittiright, that doesn't change the problem much, though22:18
mhall119it will limited the amount of 'precident'22:18
mhall119and makes the potential for more work far less daunting22:18
stgraberI believe the first one was sort of answered by the ARB asking for explicity policy changes for the unity paths a while ago, but can't hurt to have that clarified by both sides indeed22:19
mhall119it's also hard to have problems like cirular dependencies under those restrictions22:19
stgrabermhall119: single level or multiple level really doesn't change much, in either way we need to have the tools to monitor this (though shouldn't be horribly difficult as long as we don't have to remove 20 of them a week) and think of the proper way to do these removals without leaving packages around and without listing empty packages on the people's system and in the archive22:21
stgraberis there anything else to discuss at this TB meeting or can we wait till the ARB meeting on Friday? (considering we're already 21min past our allocated meeting time)22:22
pittiok, so I don't think we can discuss more at this point22:22
jonothanks everyone22:22
mhall119stgraber: I'll wait until Friday, do you have a link to the ARB agenda?22:22
pittionce the ARB answers that and makes a proposal for extending that policy, voting on it should be quick22:23
stgrabermhall119: sure22:23
stgrabermhall119: https://wiki.ubuntu.com/AppReviewBoard/Agenda22:23
mhall119and thanks everyone for discussing this22:23
pittithanks everyone22:24
pittinext chair would be kees22:24
pittiI'll send the meeting notes tomorrow morning; good night everyone!22:24
=== 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
meetingologyMeeting ended Mon Feb 20 22:24:50 2012 UTC.22:24
meetingologyMinutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-20-21.08.moin.txt22:24
meetingologyMinutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-02-20-21.08.html22:24

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!