[App-review-board] ARB queue status

[Daniel Holbach]

Hello everybody,

Am 25.11.2011 09:43, schrieb Daniel Holbach:
> Am 24.11.2011 20:17, schrieb Allison Randal:
>> We just started a "patch pilot"-like schedule, to have reviewers
>> clearing the queue each week:
>>
>> https://wiki.ubuntu.com/AppReviewBoard/ReviewShifts

How are the shifts working out for everyone?

(I know that http://pad.lv/886366 currently is sort of a blocker, but
via LP it should still be possible to review, right?)

>> I had the first shift, and in that time was able to package one app from
>> scratch, do a code review on another, get another submitted upstream to
>> Debian (which has now been accepted, huzzah!), and comment on a couple
>> of others. So, I'm hopeful that we'll catch up pretty quickly this way.
> 
> It's great that one package got accepted in Debian! I remember a
> discussion at UDS where we wondered if it'd make sense to be more
> up-front about the different options which package submitters have
> including the impact and expectations. Is this something we'll
> document/announce/tell people this cycle?

Is this maybe part of a blueprint somewhere?


>> And, we've also invited others to help do reviewing and packaging, as
>> non-voting participants. I had one person asking about it on IRC during
>> my shift, and another emailed me this week. Given your experience
>> building up community teams, perhaps you have some suggestions on how to
>> organize the non-voting reviewers? i.e. should we create a launchpad
>> team for them, sign them up with us for review shifts, etc?
> 
> A Launchpad team doesn't hurt. Maybe you can make use of it in the
> myapps application at some stage. Personally I would
> 
>  - make it clear that others are invited that they can contribute by
>    reviewing/testing in the docs, blog about it
>  - post to social media when your shift starts and you want others
>    to help out
>  - explain where the ARB is hanging out, so you can generate some
>    discussion (is it #ubuntu-app-devel?)
>  - send reports of things that got done
>  - ... and if this takes off, it maybe might make sense to have a
>    meeting now and then

I didn't hear any comments. Does this make sense?


>> One thing that still remains a difficult issue is installing in /opt. I
>> can package an app in an hour, and then spend 3 more getting it to work
>> in the non-standard install location. If it takes me that long, I'm sure
>> it takes a new developer substantially longer. This might be improved
>> with clearer documentation, showing how to solve common problems with
>> installation in /opt. Again, I think your experience could be helpful here.
>>
>> Another blocker is when packaging an app reveals a bug in a toolkit the
>> app is using. The one I packaged last week has a bug in python-pyglet
>> with either bamf or the Unity launcher, that is causing the Launcher to
>> think it's an application called 'panel' and to show multiple windows,
>> even though it only has one. I'm not even sure who to report the bug to.
>> You can find the app in my PPA, called 'crabhack':
>>
>> https://launchpad.net/~allison/+archive/ppa/+packages
>>
>> If it weren't for this bug, we could have voted and approved this app
>> this week. It's a pretty little retro scroller game.
> 
> It's good to see you are getting a handle on the categories of issues
> that block you. Personally I think I would start a bigger discussion
> about this on ubuntu-devel at . We should make it much much easier to do
> this. If our platform needs to be fixed to look in /opt for certain
> things, maybe we should file bugs on all the necessary bits and tag them
> with opt-installation or some such to be able to track these issues better.

Was this maybe raised as part of a bigger discussion somewhere else?

Have a great day,
 Daniel

-- 
Get involved in Ubuntu development! developer.ubuntu.com/packaging
Follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to