<br>Hi Tom<div><br><div class="gmail_quote">On Wed, Feb 23, 2011 at 3:55 AM, David Farning <span dir="ltr"><<a href="mailto:dfarning@activitycentral.com" target="_blank">dfarning@activitycentral.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
weird. this just came through today. do you still have question that<br>
I could help you with?<br>
<font color="#888888"><br>
david<br>
</font><div><div></div><div><br>
On Mon, Feb 14, 2011 at 3:19 AM, Tom Parker <<a href="mailto:tom@carrott.org" target="_blank">tom@carrott.org</a>> wrote:<br>
> On Sat, 2011-02-12 at 08:43 -0600, David Farning wrote:<br>
>> We never had the resources to test new activities before release in<br>
>> a.sl.o, as a result activities are released before qa. This has been<br>
>> causing increasingly more trouble. As the quality assurance on a.sl.o<br>
>> falls, fewer deployments use it:(<br>
><br>
> Releasing with no QA at all is a very undesirable situation.<br>
><br>
> I think we are technically capable of performing approvals, but our<br>
> resources are quite limited. We meet every Saturday, so requiring our OK<br>
> would cause significant delays. In QA mode, is there a public "beta"<br>
> site where the activities are publicly available until they are<br>
> approved? I sometimes see several releases in one day, I don't know if<br>
> this is due to feedback from downloads via the aslo site, they rarely<br>
> have release notes to explain what is going on.<br>
><br></div></div></blockquote><div><br></div><div>We don't have that site, our thinking in that regard is that we should be as transparent as possible and also as fast as possible publishing activities. We have only a model of non-trusted and trusted activities descript in </div>
<div><br></div><div><a href="http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy">http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy</a></div><div> </div><div><br></div><div>About release notes we are working in a new aslo that makes them necessary when uploading or updating new versions of activities. </div>
<div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
> If activities are going to be approved, what is the criteria for<br>
> approval? Obviously, the occasional releases that don't start or don't<br>
> work at all shouldn't be approved. Should the recent batch of games<br>
> which consume 100% cpu be allowed (I would say no)? What if the previous<br>
> version(s) also did so (much more difficult)? We could say a release<br>
> should introduce no new regressions, but what about new features that<br>
> have bugs? What about bugs that are fatal but rare (like the physics<br>
> core dump on scribble (vaguely recall this might be fixed now))?<br>
><br>
> Are some activities more important and held to a higher standard (such<br>
> as the set that can't be deleted) and others less important and so held<br>
> to a lower standard?<br>
><br>
> How many different releases should they be tested against? We can<br>
> dedicate a few XO-1s to different builds for this purpose, but we don't<br>
> have many XO-1.5s in Auckland to do that.<br>
><br>
><br></div></div></blockquote><div><br></div><div>I Think this can be answered by the non-trusted, trusted model, we can also fix regressions holding back new versions and if possible erasing those versions that had introduced serious bugs with admin permissions.</div>
<div><br></div><div><br></div><div>Cheers!. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
><br>
><br>
_______________________________________________<br>
olpc-nz mailing list<br>
<a href="mailto:olpc-nz@lists.laptop.org" target="_blank">olpc-nz@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/olpc-nz" target="_blank">http://lists.laptop.org/listinfo/olpc-nz</a><br>
</div></div></blockquote></div><br>
</div>