On Tue, 3 Aug 2010, Joe Buck wrote: > On Mon, Aug 02, 2010 at 05:51:13PM -0700, Paul Koning wrote: > > gcc and gccint docs are actually pretty reasonable. (Certainly gccint is > > vastly better than some of its siblings, like gdbint.) But very little of > > it is generated and very little of what comes to mind as possible subject > > matter is suitable for being generated. > > RMS explicitly blessed generated cross-references and the like under the > GPL. > > So one way to move forward is to effectively have two manuals, one > containing traditional user-written text (GFDL), the other containing > generated text (GPL). If you print it out as a book, the generated > part would just appear as an appendix to the manual, it's "mere > aggregation".
The following is my personal opinion. We want to move forward with the transition of target macros to hooks, we want to be able to convert each macro's documentation to hook documentation in target.def, we want to be able to move existing documentation for target hooks there, we want this to be possible for people maintaining their own non-FSF versions of GCC, we want to be able to do similar things with other sorts of documentation based solely on the technical judgement of relevant maintainers while keeping it properly integrated with related documentation, and we do not want this to need approval from RMS or the FSF for each patch. Though it would probably be better for people doing hook conversion patches to include doc conversion and send them all to RMS rather than not including doc conversion and not pointing out to RMS every time such a patch runs into a legal issue. The FSF's responsibility for legal matters under the Mission Statement comes with a duty to the developers not to get in the way of the "Patches will be considered equally based on their technical merits." principle from the Mission Statement. The FSF is failing in its duty to what was traditionally considered one of its flagship projects. If this has not been brought up with the full board of directors of the FSF, it is time that it was so brought up. Richard may have the right point in <http://gcc.gnu.org/ml/gcc/2010-07/msg00411.html> regarding problems with FSF leadership. I support the FSF's various campaigns for freedom and against closed devices and systems, but I get the impression that they have been losing sight of the needs of their traditional flagship projects lately. -- Joseph S. Myers jos...@codesourcery.com
