<br><br><div class="gmail_quote">On Sat, Dec 20, 2008 at 12:50 PM, Kees Cook <span dir="ltr">&lt;<a href="mailto:kees.cook@canonical.com">kees.cook@canonical.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Dec 19, 2008 at 08:57:58PM -0500, Cody A.W. Somerville wrote:<br>
&gt; To start the ball, I&#39;ll throw an idea out: the introduction of multi-tier<br>
&gt; system that would classify an update based on an agreed set of quantitative<br>
&gt; and qualitative criteria such as where the component falls in the stack (ie.<br>
&gt; distinction between the kernel, desktop environment, and an application),<br>
&gt; popcon score, etc. etc. Each tier would demand a different degree of<br>
&gt; testing, verification, time in -proposed, sign off from different parties,<br>
&gt; etc. That way we ensure appropirate people are looking at the SRUs,<br>
&gt; appropriate testing is occuring, and appropriate happiness is occuring! :)<br>
<br>
</div>Regressions are avoided by a larger variety of people doing testing.<br>
Not enough people currently give feedback on -proposed. &nbsp;Adding tiers<br>
to -proposed would reduce the number of people testing each tier. &nbsp;I think<br>
this would result in a net loss.</blockquote><div><br>It would be a net loss if it were to work the way you describe. -proposed would not be tiered, the classification of an SRU would be. The classification would dictate the amount of testing required before being deployed to -updates, that way we can ensure that riskier SRUs *do* get the right people and the right number of people looking at them.<br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I would propose that increasing the number of people giving feedback on<br>
-proposed would be the better solution. &nbsp;I don&#39;t have a specific plan<br>
for how to implement that, but it seems that a tighter communication loop<br>
between people using -proposed, LP, and a log of what they&#39;ve installed<br>
and when (some kind of additional bug-filing wizard) could reduce the<br>
technical knowledge needed to provide useful feedback on proposed.<br>
And let them revert/blacklist an update easily.</blockquote><div><br>Improved tools is an excellent idea.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<font color="#888888"><br>
--<br>
Kees Cook<br>
Ubuntu Security Team<br>
</font></blockquote></div><br>Cheers,<br clear="all"><br>-- <br>Cody A.W. Somerville<br>Software Systems Release Engineer<br>Custom Engineering Solutions Group<br>Canonical OEM Services<br>Cell: 506-449-5899<br>Email: <a href="mailto:cody.somerville@canonical.com">cody.somerville@canonical.com</a><br>