The editorial committee is in charge of approving the inclusion of new packages in the library. This means that they assure that new contributions
Software specifications and implementations should be submitted to the editorial committee for approval. This can be done by sending mail to the committee indicating where the (PostScript) documentation and code can be found. After some reasonable amount of time, you should receive feedback from the committee about the specification and what, if anything, needs to be changed. The usual procedure is that someone from the committee is assigned to be (or volunteers to be) the primary reviewer and sends comments on the submitted package to the committee and to the authors of the package. Discussion then proceeds among the committee members and the authors until a consensus is reached about how the package should be modified before being accepted. When the package has been modified, the authors should again notify the editorial committee to let them know what has changed so a decision about acceptance of the package can be taken.
The discussion of specific packages are logged on the Editorial Committee web page. Reading the feedback given on other packages can be quite instructive as a means of learning what the editorial committee is looking for.
One should write a specification for a new package (Chapter 2) and submit it to the editorial committee for approval before submitting the package for inclusion in the internal releases (and ideally before implementation of the package). This assures that time is not wasted in fixing code that may later be changed due to the recommendations of the committee. However, since it can take some time for the committee to process submissions, packages that are to become part of the library (as opposed to being listed as CGAL Extension Packages) can be submitted as detailed in Section 20.2 before approval. Inclusion in an internal release does not ensure inclusion in a public release. Only after approval by the committee will packages be included in new public releases and then only if they pass the test suite, of course.
The current members of the editorial committee are:
| Andreas Fabri | Bernd Gärtner |
| Efi Fogel | Michael Hoffmann |
| Lutz Kettner | Monique Teillaud |
| Remco Veltkamp | Mariette Yvinec |
| Sylvain Pion | Menelaos Karavelas |
| Ron Wein |
Whether you produce library code, demos, documentation or something else, if you want it to become part of CGAL, you'll have to submit it in the form of a package which has to be a folder under SVN trunk. The directory structure required for a package is described in Chapter 4.
Here we focus on how to submit a package. This section is mostly obsolete since we have gotten rid of the mail-based system for package submission in 2004.
A package has a name, which identifies it. This name should obey the same rules as for C identifiers: it consists of letters, digits and underscores and it does not start with a digit. Choose a name that is descriptive, yet not too long (under 25 characters). If a package deals with objects of a particular dimension, then use the suffixes _2, _3, and _d, especially if there exists (or may exist in the future) a package with similar functionality in different dimensions. Examples of good package names are Triangulation_2 for a package dealing with triangulations of points in the plane and Min_ellipse_2, which contains an algorithm that finds the minimal enclosing ellipse of a set of points in the plane. The package names pm and arr are a bit too terse. Planar_map and Arrangement (or Arrangement_2) are better.
There are several reasons why a submission may not succeed. In most cases the confirmation message will state that an error occured. In some cases, you will not get a confirmation message at all.
The following is a list of reasons why a submission might fail.
Requirements:
Recommendations: