<div class="gmail_quote">On Fri, Nov 6, 2009 at 12:54 PM, Cory K. <span dir="ltr"><<a href="mailto:coryisatm@gmail.com">coryisatm@gmail.com</a>></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;">
Now, this might seem like I'm poo poo'in' on the idea a bit but hear me out.<br>
<br>
To this point, generally, applications work in Studio. Bugs are filed<br>
aginst apps and are usually taken care of by upstream. So, I would like<br>
to know, with this idea there had to have been some inspiration.<br>
Something that sparked this idea for you Eric. What was it?<br>
<br></blockquote><div>Well the moment that triggered this thought was an e-mail sent to me by a member of my LoCo that read<br>"I would like to be a member of the Ubuntu Studio testers. I have been
using it for a long time." <br>and I thought back to a large number of people who had e-mailed the users or dev list saying 'yes, I'll help test ubuntu studio' but failed to continue through with many (if any) test reports.<br>
<br>As I sat and thought of the response I should send to this latest e-mail, it became clear that there has to be a better way to organize testing. Furthermore, I didn't want to have to write every instructional e-mail to new testers myself. A community of testers seemed to be the natural solution, and a solution that was used for this same problem in Ubuntu in general. The community or 'team' structure also encourages participation and growth, which I thought would be a great things to see in Ubuntu Studio Testing.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
OS-wise, Studio does have a couple of bugs I really wanna see taken care<br>
of this cycle. ie: *-menu, *-controls and *-settings. But aside from<br>
that I'd like to know what would be the specific focus of testing that<br>
procedures would be developed from?<br><br></blockquote><div><br>I would imagine a combination of A) program testing new features (does pencil save properly, does a particular LV2 plugin crash ardour, etc...) before they're committed to release (this also would catch packaging errors such as the Ardour import bug we had a couple releases back) B) wider testing and reporting of RT issues/complications C) Ubuntu Studio specific program and settings testing (*-menu, *-controls, *-settings, etc...) D) more thorough ISO testing (might have caught the karmic issue about installing ttf-mscorefonts-installer offline)<br>
<br>This is just a quick brainstorm on the matter. I'm sure as the team is formed, more structured testing rules and policies will grow (and I'll help them grow with the input of the dev team). I'd also like to note that the dev team is more than welcome to join the testing team to help coordinate things.<br>
<br>-Eric Hedekar<br></div></div>