Possible Mentors

• Enrique Erne

• João Pais

• Another developper with experience in the compilation process of Pd-Extended

Description

Pd Extended includes code from dozens of developers. Each developer has access to the svn repository, and can add his own code on his own subfolder(s) of the /extra directory. The process allows total freedom to each developper, but already from the start there have been problems due to the independent development of externals. These problems were more evident when many externals were acessible in the same package. The main problems are

• huge number of externals and abstractions (more than 2000 files), which are not centrally listed (some not very well documented, and some even buggy)

• this leads to each developer doesn't know what others are doing. Externals with nameclashes are created, as well as (similar) repetitions of already existing externals.

The project has two goals:

• Creation and automatization of a system (or script) that tests externals and lists code inserted to svn

• Restructuring of the /extra folder into categories instead of developer folders.

Resources to start

• http://puredata.info/dev/PdLibraries - List of possible categories

• http://lists.puredata.info/pipermail/pd-dev/2009-02/thread.html and http://lists.puredata.info/pipermail/pd-dev/2009-03/thread.html - Recent threads of Pd-dev list where this subject has been discussed (the discussion goes around several threads).

Required Skills

• Time and pacience to list and test thousands of files in different plattforms (Windows, Linux, MacOs)

• Knowledge of the compilation process of Pd-Extended

• Technical and social skills to discuss with the pd-developer list on strategies to reorganize the svn commiting and compiling process of Pd-Extended

Difficulty

Not very difficult, only time consuming. The most difficult step might be getting the developer community to reach an agreement.

Possible Breakdown of Steps

For the generation of the external list:

• Go through each subfolder (library) in /extra and make a complete list of the externals (taking as basis the two lists in the bottom of this page). Bear in mind that some externals are available only in some plattforms.

• Organize the externals through categories such as name, library/path, category, description (and maybe others).

  • List all duplicates of code (different externals to do the same function).

• Test all externals (in as many platforms as possible) to make sure they're actualized. Contact developers relating buggy externals.

• Create and test a system that garantees the continuation of a automatic listing of new added externals, while permitting the liberty of each developer to commit new material. Suggestions include:

  • Obligatory documentation files added by each developer (in 0.INTRO.txt format), which will be grep'ed to make the complete external list.

  • A central tester community.

• Optionally, contact developers that didn't submitted their externals to svn, and invite them to do so.

For the restructuring of the /extra folder

• Conclusion of the discussion with the developer community about which categories should be programmed.

• Restructuring of the svn structure to allow for a code commit still in developer folders, but compilation in categories.