Hello, To land 0.81.1, which is largely about the redesign, we will need someone to write down test cases for each feature in the redesign. Eben we thought you could perhaps help out with it, so that can keep focusing on the code. What do you think?
Here is a quick proposal on how to handle test cases for the next versions. It will never be mandatory for any module (each maintainer is responsible to negotiate with Michael in the ways he consider more useful), but I'd like to try it out with glucose and a few activities. From: http://wiki.sugarlabs.org/go/TestCases To land new versions of glucose and new activities in the OLPC builds we need to: * Provide test cases for each new feature or bug fix. * Find testers to execute the test cases. A way to handle it in a distributed way and ensure it's done consistently is: * Ensure that every fix or new feature is associate to a trac ticket and that the git log for each of the related commits contain a reference to the bug. * Before closing the ticket make sure that it contains a comment with the test case (mark it by inserting a keyword in the text so that it can be extracted automatically. * When releasing a module, use a script to automatically generate the NEWS from the ticket references in the git log and the test cases (git log -> ticket -> test case). Put both in the release announcement. * Decide which modules to land together. Get the test cases from the release announcement and create a page in the wiki. Ask volunteers to execute them and report the problems they find. * Negotiate with the release manager on the base of the testing data. Marco _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar