<< Back to specification

Feedback log

The following table summarizes the input we've processed and added to the spec since the date it was announced for public review and comment. Thanks to everyone who contributed!





Several questions, we need to have some mechanism that rejects the package if it does not comply with the rules

Made the App Review section clearer, answered questions,


Question on private files AppArmor abstraction



Notes about reverse DNS naming on whitelisted locations

Added notes to table


Concerns about limitations in the helpers, misunderstanding what access is available by default

Updated the spec to include more information about how the helpers will work and what kind of access apps will have by default


Beta is a safer time to open Extras than FeatureFreeze

Updated spec


Potential package name conflicts with future Debian packages

Added a paragraph about prefixing package names with extras-


Avoid filename conflicts with a conflict checker service

Added section expanding on the conflict checker


Concern that hyphens in package names wouldn't provide the level of namespace protection that we expected

Replaced hyphens with underscores when used in package namespacing


Requested additional clarification on the requirements for package updates

Added a sub-section specifying that new package versions must undergo the same processes and checks as the initial submission.

For more details, please see the complete revision history of this page.


In the AppDevUploadProcess page it says for upload rights permission:"Physical verification: as an alternative, developers can be verified at Ubuntu events such as the Ubuntu Developer Summit (UDS), release parties, jams, etc. A set of individuals will be part of a team or review board who will be able to accept developers applications into MyApps directly. "

Can Ubuntu Developer Summit still be a "physical verification" because the Ubuntu Developer Summit is now virtual? Of course there CAN be sessions where people apply for upload permissions. However it would be super difficult to do so, especially when each session lasts a hour only, and per 6 months. Release parties and jams are not a good idea too, when upload approvers might only be able to attend one specific Local Community's event. This would cause a lot of people unable to do so.

I propose letting the Ubuntu Developer Membership Board (DMB) to do such "verification". After all, they are experts when coming up to developer membership applications such as Ubuntu Core Developer, MOTU, Ubuntu Contributing Developer and per-package uploader. We should treat the app uploaders as a per-package uploader.

However there might be an issue when people cram into a meeting (also one hour, but at least held bi-weekly) and causes the DMB to go overworking. Henceforth, having such a team wouldn't really work "physically" or even "virtually".

Also I do propose one thing: Let people in ~ubuntu-dev upload packages themselves, without needing permission to upload. After all, they already gained upload rights, so they must know the proper things they need to do, and upload properly. I think the Developer Membership Board (DMB) does trust them on that.

So probably this "approval process" should really need to be fully considered. -- smartboyhw 2013-04-14 10:34:40

Please note that feedback will be cleared out as soon as it has been addressed and (if necessary) added to the spec and recorded in the Feedback log.

<< Back to specification

AppDevUploadProcess/Feedback (last edited 2013-04-14 10:34:40 by smartboyhw)