From BlenderWiki

Jump to: navigation, search

Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

Project Schedule

This is where the project timeline will be. Note that it is still being worked on. Dates further in the future are subject to change. Nearer dates will change less.

Community Bonding Period

In the community bonding period, several test frameworks were sampled, factors such as how well it integrated into the current blender code base, and how it was built were tested. Also basic forms of test aggregation were attempted. Nothing deployable, simply a few possibilities of what could be made. In addition, mainly for demonstration purposes, several sample unit tests were developed. Tests for the Python API are written in PyUnit. Google Test has also been attempted for testing portions of the Blender Kernel, thus far with little success linking the tests into the project.

May 24 - May 31

This portion of the project will consist of developing a sample suite of unit tests. It is currently planned to base these tests around the bpy.data API set, however, at this time, it is possible to change that. These should be a rigorous suite, testing a fair amount of the public API calls available. Note that if time doesn't permit for all of the tests to be created, there will be a larger focus on the depth of the tests, rather than the breadth of all of the tests. PyUnit will be used for these tests.

June 1 - June 7

With these tests available, a simple aggregator will be formed to run these tests. This will not be like the aggregator that was used in the Community Bonding Period, but rather, it should be designed to be easily expandable. Again, CTest will likely be the platform of choice, as Blender is already using CMake as a tool to compile blender. It is possible, although unlikely, that other tools that Blender uses for compilation and linking, such as standard make and Scons will be tested for the probability of inclusion, but CMake will be the main platform. Alternatively, a simple C, or other appropriate language, file may be created to run the tests suites. Note that this aggregator should not have the tests hard coded into them, but rather, it should be built such that it is capable of finding a list of tests, possibly specified in a simple text file, but preferably capable of automatically generating the list based upon the tests placed in a particular location or directory.

June 8 - June 23

This time should be dedicated to development of other end to end and regression tests. It is much longer than the first suite because much less time was spent on it during the community bonding period. An emphasis will be put on making various forms of render based tests. At this time, it will be important to determine a good strategy for how often the test suite should be run, and, if needed to be run in multiple increments, i.e. some tests running with every commit, while others run only nightly. This section can be further split into two sections. The first being setting up the testing platforms, and the second part being creating a sample test suite for the built platforms. Note that the task of scouting for viable platforms, based upon what Blender currently uses, and the toolset provided by others, should be a 'back burner' project, while the other sections are taking place, and should be completed by the time that this section starts.

June 24 - July 1

This slot is devoted to choosing a good architecture for the testing frameworks. At this point, all, or at least most, of the testing frameworks should be have been chosen, built, have a set of sample tests written for them, and have a simple form of aggregation. However, they may not be optimally placed in the blender code base/supporting files. Also, it may be decided that it is better to link to certain test frameworks, and require that whoever runs them have that dependency installed. In other words, this week will be a form of cleanup and design for the project. It should take the previously hacked together samples, and put them together in a slightly more professional form that will hopefully have the potential to be documented, and allow for easy expansion, thus giving the project what will actually make it useful, which is to say, make it extremal easy for developers and maintainers of various pieces of code to write their own tests for their individual pieces of code. In addition, improvements upon the test aggregator started earlier will be created. These improvements will include features to make it easier to use, and seamlessly incorporate with the rest of the Blender code base. This time slot is fairly hard to predict, and it may be contracted to a day if the current project status is already very clean and already very simple to syndicate tests, or expanded up to about two weeks if the code has been previously hacked together, and the syndication of tests is very static. At this time, it is also very important that features of CMake, such as CDash, and how well it would incorporate to the current projects.blender.org website, or a different form of easily monitoring the tests' status should be started at this point. However, that is not a high priority of this section.

July 2 - July 15

At this point, the framework, or at least the back end of the framework should be almost entirely complete. This leaves three major areas for developing the whole system. First, A front end needs to be made, either for the blender servers, developers who have check out the source code, or preferably both. Second, The test suites must be expanded. The ones made earlier in this project work for demonstration purposes (as well as actual tests), but a richer set of tests must be created to aid developers make their own tests. Third, documentation must be created. This should be very straightforward documentation that a developer who has been working on a piece of code for a while wouldn't mind reading when it's done (as to add it to the testing repository). This section of time focuses on the first two goals. The main focus is on test suites. Not only do these tests need to act as good efficient tests, but they will also serve as samples for the future. Also, the project started in the previous section is brought up to the front. Not as the main project, but as a co-project with this one. As the timeline approaches this time slice, it is likely that this slice will be divided into two sections.

July 16 - July 23

This week is simply a buffer week. It is likely to be removed later, but if any of the sections up to now run behind, it will cut into this week, and if everything up to this week has been on time, then I will proceed to the next task. Also note that preliminary portions of the third task in the last section will begin during this time chunk.

July 24 - August 3

This begins the documentation/packaging phase. In this phase, the documentation for the basic workflow that these tests have will be created. Developers should be able to quickly see how it works, to encourage future testing. More details will be added as the project unfolds.

August 4 - August 11

By this time, the entire aggregation system should be complete. At this point, any requirements that the Blender Community has before it can be incorporated into the code base will be had, and hopefully, it will be added to the code base by the end of the period. In addition, if there isn't any major changes needed, and it's not done already, I hope to help improve various portions of Blender's API documentation.

August 12 - August 20

By now the project should be completely over. Documentation should be sent to Google, and any other remaining loose ends that last will be taken care of. If needed this time slice will be shrunk.

Page Siblings

User:LeifAndersen/GSoC2010/schedule