<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. &nbsp;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). &nbsp;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. &nbsp;Just placing increased controls<br>is not sufficient to ensure uploads to -proposed will be good. &nbsp;The only<br>actual regression in a -proposed upload I&#39;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.&nbsp; This will make sure that some eyes get on it, without the necessity of taking an archive admin&#39;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.&nbsp; I say a team PPA because then you won&#39;t be filling up your already possibly in use personal PPA that people might subscribe to who don&#39;t need the fix yet. &nbsp; Typically you aren&#39;t looking for linda/lintian/packaging changes on an SRU but instead you want functionality.&nbsp; 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.&nbsp; 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>