[Blueprint appdev-r-arb-review] Ubuntu App Review Board - Update and Planning for R cycle
David Planella
david.planella at ubuntu.com
Thu Nov 1 10:43:47 UTC 2012
Blueprint changed by David Planella:
Whiteboard changed:
Streamlining reviews
- ----------------------------
+ * Some ideas from the App Developers Roundtable
+ * Require just one vote
+ * Currently is 3 -- might be better to just have 2 reviews rather than "votes"
+ * Any ubuntu developer as a first review
+ * Currently this is ARB-contributors team
+ * why not just add ubuntu-devel to ARB-contributors team?
+ * "archive admin role" -- license check, sanity check from ARB member proper
+ * Archive admin in Ubuntu includes a lintian check -- do we have an ARB-Lintian profile? We have a work item for it already
+ * Relax copyright checking (check with the TB)
+ * We have some tooling but not ideal to validate the dep5 copyright format
+ * Ideal tool would let us white-list some licenses and have the tool scan the dep5 copyright file to make sure it lists every file under at least one of these licenses; failures can be looked at manually.
+ * Restrict code review strictly to security checks
+ * Limit how we can
+ * AppArmor profiles can help us here (eg even a bad app would be ok)
+ * Could we use autopkg test to verify that app at least starts?
+ * Interestingly this provides a convenient way to inform how to write tests.
+ * Anything that can be automated is a good quality check that doesn't add time for us
+ * Integrate arb-lint into Quickly through proper Lintian checks
- * Some ideas from the App Developers Roundtable
- * Require just one vote
- * Relax copyright checking (check with the TB)
- * Restrict code review strictly to security checks
- * Integrate arb-lint into Quickly through proper Lintian checks
+ * Some other ideas
+ * Close the queue until it has been cleared out
+ * Review order should be FIFO imong the unreviewed
+ * Among the reviewed it should be FIFO for most recent comment
+ * Forward-copy apps to the next release
+ * Current process is to ask them to refile the app for queue, people who've had their app take months are more likely to drop out here.
+ * Desire: run app against the new automated checks, then forward copy it if it passes; warn them if otherwise.
+ * This needs to be a reliable test (but since we're supposed to have a reliable release pocket this should be ok when automated)
- * Some other ideas
- * Close the queue until it has been cleared out
+ * Handling exception cases
+ * not good enough
+ * apparently malicious or dangerous
+ * needs system access
+
+ New model proposal:
+ * Technical review - any Ubuntu developers
+ * Compliance review - the ARB
--
Ubuntu App Review Board - Update and Planning for R cycle
https://blueprints.launchpad.net/ubuntu/+spec/appdev-r-arb-review
More information about the App-review-board
mailing list