April 13, 2011

The TLC will meet by teleconference on April 13, 2011 at 4:00 PM EST. To join the teleconference, see FutureMeetings.

Agenda

Current Business

1. Visual studio support (see notes from Gus Gassman below)
2. CoinAll 1.6 progress
   • Revisiting the idea of not installing autoconf headers (should we wait?)
3. Moderation system
   • Do we want to have site-wide default moderators?
   • How to implement having multiple moderators for one project?
4. Doxygen documentation update on server
5. Deactivate the RPX project?
6. Installers
7. Hudson status

Pending Business

1. Mailing lists

Notes

1. There was a discussion of proposed Visual Studio project file organization. Gus Gassmann participated in the discussion to represent the views of developers who depend on the existence of visual studio project files to build OS. The issue is over the usefulness of the so-called "split" build. His position is that the split configuration transfers all the burden of version control, downloading, updating, compiling and maintaining COIN-OR projects to the user. The main argument he sees seen in favor of this move is that it "eliminates duplication and saves disk space". He does not find this argument persuasive. The cost of disk space is more than compensated for by the convenience of the classic build. It is cumbersome and error-prone in the extreme to maintain a complicated project like OS with the tools provided in the v10alt distribution. The net effect is likely going to be a loss of users. The OS developers walked away from MSYS over just such an issue. Another argument advanced in favor of the split configuration is that it allows the user flexibility as to how to organize the directory structure. However, the vcproj files do make the same rigid assumptions about the location of the .lib files needed to build a project that the flexibility is an illusion. He would like to see a merging of the "classic" and "split" configurations to the effect that the directory structure of the binary files be taken from the split configuration, and all the complexity of the build, including dependencies, be taken from the classic configuration. Gus's opinion is that a user cannot be expected to build eighteen separate projects individually, let alone in the correct sequence. All the user should be required to do to properly update a project is to start Visual Studio and push F7. That is how it used to work in the past, and that is how it should continue to work.

There was a discussion of this situation and Lou Hafer explained that the split build was an experiment that could be abandoned if not found useful. Furthermore, the intent was not necessarily to stop maintaining the "classic" build. In fact, the v10 "classic" build files still exist in trunk and were just accidentally not merged to stable. This will be done and we will see about taking some of the "good" parts of the split build and moving it to the "classic" build, as suggested by Gus.

2. There was a discussion of how to proceed with respect to the question of installing the headers automatically generated during configuration. It was decided to pursue a scheme in which there will be both an installed (public) auto-generated header and an uninstalled (private) header. The private header will only for internal use in building the project itself (this header will be the already-existing one named config_xxx.h), whereas the public header is for the export of APIs, etc. required for linking to the library externally. There will be a dummy header that will contain the logic as to which of these two is the right one to include (or whether the static header intended for use with Visual Studio builds should be included instead).

3. It was decided to try to go for a system in which the moderation requests for tickets are sent to the ticket reflector mailing list.

4. Remaining business was tabled.

Respectfully submitted,

Ted Ralphs, TLC Chair