<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think that the goals are consistent. The trick is how we instantiate the
<br>goal in policy and procedure.<br><br>The old policy of motu-sru approving placed too high a barrier to entry,<br>primarily due to manpower issues in Universe (IIRC). The current policy of<br>allowing any MOTU to upload based on their judgement places it too low.
<br><br>The trick now if finding the correct balance. Just placing increased controls<br>is not sufficient to ensure uploads to -proposed will be good. The only<br>actual regression in a -proposed upload I've helped people get out from under
<br>recently (downgrade back to the published version) was in Main.<br></blockquote></div>I was briefly discussing this with Emmet and we were both in agreement
that some sort of peer review system should be re instantiated.<br><br>The idea that we had thought was perhaps requiring two acks from ~ubuntu-dev members. This will make sure that some eyes get on it, without the necessity of taking an archive admin's time to review the entire thing.
<br><br>Another idea I was proposing was maybe requiring it to be sent to an ~ubuntu-dev or ~motu PPA. I say a team PPA because then you won't be filling up your already possibly in use personal PPA that people might subscribe to who don't need the fix yet. Typically you aren't looking for linda/lintian/packaging changes on an SRU but instead you want functionality. This could then lower the barrier for people having to do large SRU builds locally since they could just wget the debs from the team PPA. Also, could SRUs be cross pocket copied over from the PPA to -proposed this way?
<br><br>-- <br>Mario Limonciello<br><a href="mailto:superm1@gmail.com">superm1@gmail.com</a>