18:25:03 #startmeeting ARB meeting 18:25:03 Meeting started Fri Jan 27 18:25:03 2012 UTC. The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. 18:25:03 18:25:03 Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired 18:25:20 sorry if I'm a bit distracted, I'm being poked on a few channels at the moment ;) 18:25:37 #link https://wiki.ubuntu.com/AppReviewBoard/Agenda 18:25:55 it's ok, I'm still trying to wake up :) 18:25:57 #topic Apps which modify system settings (ubuntu-tweak, grub-customizer) -- AndrewMitchell 18:26:57 we had a brief discussion about this one in #ubuntu-arb yesterday, that we have some submissions which fiddle with the system (installing packages, touching files in /etc) 18:28:01 currently we have a general policy that such things aren't allowed, but there's no definitive place we can point people at for what's acceptable 18:28:15 that's true 18:28:26 there's the early documents, but it's not a clear list 18:28:36 it would be better to have one page 18:28:39 right, I think we should go with a whitelist on that rather than a blacklist 18:28:42 https://wiki.ubuntu.com/AppReviewBoard/Review has some of our other rules, PostReleaseApps/SecurityChecklist has a whole lot more 18:29:24 stgraber: I like that, it has a more positive tone 18:29:27 along the lines of is allowed to write to an app specific directory in the user's home directory and can use gconf/gsettings to affect desktop settings if that's the result of a user's direct action in the UI and is revertable 18:29:28 I'd like to be able to reject those apps with a good response, and get information on developer.ubuntu.com linking to what we'll accept 18:30:19 stgraber: pong 18:30:26 I don't want an app that starts messing in gconf/gsettings when it opens without it being a visible opt-in switch 18:30:54 alright 18:31:23 you've probably seen that there's a fair discussion on ubuntu-desktop about ccsm & related apps 18:31:42 indeed 18:32:45 indeed and I'm not necessarily against apps like that in extras, but they shouldn't do anything by default, make it clear to the user about what will be changed when they click something and ensure that reverting the change works 18:33:04 (so effectively, that'd be a no-go for ccsm as the part about reverting changes doesn't seem to work too well ;)) 18:33:09 unfortunately ubuntu-tweak is a bit of a kitchen sink, it adds/removes packages & manages PPAs as well 18:33:36 right, ubuntu-tweak is a clear no-go if only for its use of gksudo, touching /etc and adding repositories 18:34:02 we don't even allow packages in the archive to add PPAs (well, except the packaging tools themselves) :) 18:34:08 stgraber: so is ccsm being dropped from the archive? 18:34:24 highvoltage: as it stands, it's likely 18:35:01 Before you drop it can someone see how much work it's going to be to make the screen magnifier accessible in other ways? (including the options to set type of zoom and level of zoom) 18:35:04 grub-customizer has an open debian ITP, so probably better to help the author get it in there 18:35:35 highvoltage, Pendulum: it might get dropped, anyway, that's not a discussion for the ARB to have, please discuss it on the mailing lists :) 18:35:38 Pendulum: we're not the ones dropping it, we're trying to sort out what's acceptable for extras.ubuntu.com 18:35:51 ajmitch: okay, couldn't tell who was making the final decision. Sorry! 18:36:18 ajmitch: yes, agreed grub-customizer is better through the Debian process 18:36:32 ajmitch: right, I don't believe grub-customizer would be suitable for the ARB, so we should indeed drop it and help get it in Debian 18:36:42 ok, I'll try & put aside some time for that & tell them in the rejection email :) 18:37:31 so as a general rule, the AppReviewBoard/Review page is a good place to put the guidelines about what an app can do? 18:38:27 ajmitch: It might be worth creating a simple AppReviewBoard/Review/Guidelines page 18:38:36 alright 18:38:37 that's just a list of "what we accept" 18:39:25 I can add that, and a canned response on the Responses page 18:39:48 that'd be grat, thanks 18:39:52 *great 18:40:13 awesome, thanks! 18:40:32 #action ajmitch to reply to grub-customizer and have the packaging process continue in Debian 18:40:32 * meetingology` ajmitch to reply to grub-customizer and have the packaging process continue in Debian 18:40:56 stgraber: thanks, you're quicker than I am :) 18:40:58 #action ajmitch to work on AppReviewBoard/Review/Guidelines (basic list of guidelines for app going to extras.u.c and some canned responses) 18:40:58 * meetingology` ajmitch to work on AppReviewBoard/Review/Guidelines (basic list of guidelines for app going to extras.u.c and some canned responses) 18:41:37 I guess based on that page we can then go through the queue and do some mass rejection? (not sure how many we have but at least ubuntu-tweak should be rejected) 18:41:56 there shouldn't be too many 18:42:40 good 18:42:47 #topic Complexity criteria of app submissions 18:43:06 so to quote what I said yesterday on IRC 18:43:28 23:46 < stgraber> 15:41 I believe they are basically "no bundled libraries" (which gets us rid of 99% of the java stuff) and "no more code than a human can reasonably read and understand in an hour" 18:43:46 (yeah, I've been copy/pasting that one a few times ;)) 18:44:09 no bundled libraries at all? 18:44:11 we did allow bundling some libraries if necessary, last time we sorted out rules 18:44:26 just not bundling updated copies of what's in the archive 18:44:32 like, if a python game uses a couple of self-written objects for data? 18:44:37 ah, yes agreed 18:44:39 certainly not bundling .jar files though :) 18:44:44 that sounds very nice, especially for the arb reviewers, but wouldn't that make it hard to ship games? 18:45:03 if the "library"/"module" is part of the upstream code, fine 18:45:25 I just don't want to have apps containing bundled external libraries in their code 18:45:27 (actually, scratch that, I was thinking of things like Oil Rush, but that's not even an ARB app in the first place) 18:45:36 because it becomes a security/bugfix/legal nightmare pretty quickly 18:45:47 yup, we don't want to be maintaining that 18:47:05 not sure how we want to word it in the guidelines, but the idea is that we'd reject anything that bundles libraries/modules/whatever that can be found as a separate entity (so outside of the upstream project) 18:47:41 We can word it mostly positively 18:49:00 You can include any libraries that are part of your app, for example... 18:50:04 yeah, we should try to be a bit positive about it (though it's a bit difficult to make that kind of criteria positive ;)). 18:50:13 If your app depends on external libraries, please make sure that your app runs on the current versions shipped in Ubuntu. 18:50:27 it's also hard to make "your source is too big" positive :) 18:50:41 (that implies a negative, but states it as a positive) 18:50:43 I'm sure we'd have submissions arguing on the "are part of your app" part saying that their upstream "source" tarball contains all these .jar and so it's "part of their app" :) 18:51:06 wendar: +1 for that one 18:51:08 stgraber: fine, but we also have requirements that the app be buildable from source, afaik 18:51:39 ajmitch: indeed, which is why we should have rejected all of these with bundled .jar a long time ago 18:51:40 the page links to the licensing policy which requires full source 18:52:02 yeah, I should have rejected those that I've seen, sorry 18:52:46 ajmitch: How about something like "Our focus is on lightweight apps. To give you a general idea, we're looking for the kind of apps that could be reviewed in about an hour reading through the code." 18:53:03 wendar: that sounds good 18:53:15 wendar: that in addition to the "If your app depends on external libraries, please make sure that your app runs on the current versions shipped in Ubuntu." would be great 18:53:22 an hour might be a little too lightweight, but it's a start 18:53:42 yeah, I could see spending a couple of hours 18:53:52 it's just to give them a rough guideline 18:54:12 with review here meaning just scanning through the code and figuring out what the app does, in that hour I didn't count licensing review or any actual testing of the app and packaging 18:54:16 (and programmers always underestimate, so if we say one hour, we'll probably get 5) 18:55:11 There's an empty page at https://wiki.ubuntu.com/AppReviewBoard/Review/Guidelines if you want to put them there 18:55:32 wendar: can you add these two to the guidelines? 18:55:52 yes, will do 18:57:06 #action wendar to update AppReviewBoard/Review/Guidelines to include a note on bundling libraries and complexity (review time) criteria 18:57:06 * meetingology` wendar to update AppReviewBoard/Review/Guidelines to include a note on bundling libraries and complexity (review time) criteria 18:57:21 #topic General status of the ARB queue 18:57:59 so the queue still looks pretty long 18:58:35 it seems like the budapest sprint knocked a few off the list, and you've done a good job with getting some lenses in 18:59:03 I'm trying to find spare time to focus on 1 or 2 apps at a time & try & get them through 18:59:11 if there's something I should/could look at let me know 18:59:28 highvoltage: 'all of the above'? :) 18:59:55 I'm not sure all the changes that were listed on the mailing list by non ARB members have been applied to the queue (these from Daniel and Michael), would be good to make sure they didn't do these reviews for nothing 19:00:11 the myapps page looks to be sorted by submission date (or ID) now 19:00:51 ajmitch: seems to be by ID 19:01:27 https://lists.ubuntu.com/archives/app-review-board/2012-January/000274.html 19:01:36 ^ dholbach's reviews 19:01:43 which would end up being by submission date, since they're auto-incrementing 19:02:12 https://lists.ubuntu.com/archives/app-review-board/2012-January/000314.html 19:02:18 ^ mvo's reviews 19:03:02 wendar: right, by initial submission date, not by last submission (which is shown as the Since. column) 19:03:55 doesn't really matter about the particulars of the sorting, I was more suggesting we work from the top down, to get the oldest ones moving 19:04:01 highvoltage: can you look at these two e-mails and make sure the changes have been sent through myapps? 19:04:17 stgraber: ok, I can do so tomorrow 19:04:48 #action highvoltage to make sure Daniel and Michael's review have been sent through MyApps 19:04:48 * meetingology` highvoltage to make sure Daniel and Michael's review have been sent through MyApps 19:04:51 stgraber: aye, I guess last submission could be useful for watching what's been updated 19:05:13 wendar: indeed 19:05:56 anything else about the queue? 19:06:18 * ajmitch has nothing more to add at the moment 19:06:24 Just a quick reminder to not touch the PendingQA ones, hopefully these will be moved to published soon (still waiting for the updated software-center) 19:06:27 voting on the list seems to be a good way to do it 19:07:16 at the moment we need to use some hybrid MyApps/package metadata hack to get things to show up on the software-center, so before uploading a package to extras.ubuntu.com, please let me know and I'll make sure everything is right 19:07:21 #topic Chair for next meeting 19:07:25 ok 19:07:27 any volunteer? 19:08:01 ok I'll bite 19:08:08 * ajmitch can do it, with sufficient caffeine 19:08:10 #action highvoltage to chair the next ARB meeting 19:08:10 * meetingology` highvoltage to chair the next ARB meeting 19:08:22 #topic AOB 19:08:25 anything else? 19:08:36 none from me 19:09:04 nope, exhausted busy conferencing :) 19:09:05 just a general note that filing bugs on developer-portal can be useful if there are things that annoy you about myapps 19:09:14 (or from too much pizza) 19:09:42 #endmeeting