On 08.09.2008, at 10:59, Fabien Costantini wrote: >> Creating ranges of STR worked very well last time. I suggest that we >> simply use a group of STRs, describing the help files that need their >> contents copied over. If marked "active" and "done" correctly, we >> will >> not have any duplicate work. > I didn't understand this one could you give an example of procedure ?
Sorry, I mixed two things into one. When we moved STRs from 1.1 and 1.2 to 1.3, Greg made a list of ranges (1-999, 1000-1999, etc.) and developers picked a range, marked it as "in progress", then marked it "done". That way, we had the STRs moved in no time and with no double work. This time, we should do the same, but the items are HMTL files from the "documentation" directory. A developer marks that range "in progress", then moves the existing docs from the HTML file into Doxygen format (wherever it needs to go), and finally marks te range as "done". To administer this and avoid duplication, I suggested creating an STR for each range of html files. Whoever wants to doxyfy some files looks for an ST that is "new", marks it as "active" with his name. After finishing the work, commit it and mark the STR as "done". As soon as all of the existing HTML doc is ported, we may (or may not) have another round going through the header files, finding functions that were previously undocumented (actually, Doxygen will give us a list of those if we ask). >> Anyone who can make a list of files in the /documentation directory >> and split them into STR's? > I could do that, I checked there is about 300+ files to check and > comment (headers and sources) while doing the job. Great. Please go ahead. > While waiting for your merge (for which I quite agree it's wiser to > wait for, before we add comments ;-)), I'll see what I can do to > develop quickly a simple tool that automates as much as possible the > first increment task (getting most of the class methods comments > from html into the src files and also generating a comment file list > for the unresolved comments, ready to be included in the proper > format in the srcs but manually (like typedefs, enums, custom > comments,...). > This way a class could be commented in few minutes (most of the job > would be made automatically, and the unresolved comments would not > be lost as we would have a report with a doxygen-formatted comments > to be checked for add/added manually. A simple scripting editor and drag'n'drop are your best friend here ;-) Matthias ---- http://robowerk.com/ _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
