Hello everyone! A while ago I finished writing my diploma thesis with TeXmacs. On the whole it was a pleasant experience, but I did encounter a number of bugs: errors as well as inconveniences. Some of these I did report on the ML, others I did not report.
All in all these issues were so numerous that I could not recommend TeXmacs for production use to anyone but a TeXmacs enthusiast. I, however, am an enthusiast. Therefore I would like to ask the question how we can work towards a more stable/reliable TeXmacs. This work naturally has two aspects: - bug reporting - bug fixing In both departments there is a lot of room for improvement. In my opinion these include: Reporting: - Most issues are reported only on the ML, which is bad for a number of reasons. - There is the Savannah bug tracker, but it is not used as actively. - The testing of TeXmacs is no coordinated effort. Bugs are found when a user stumbles upon them. - There is no repository of test-case documents, except the ML archives. Fixing: - Nobody seems to feel responsible for the Savannah Bug-Tracker. The bugs entered there appear to be ignored. - Henri does an admirable job of responding to user support requests, but, as I see it, one man can only do so much. - IIRC Joris once stated that he does not have the time to go on long bug hunting expeditions and rather wants to implement the new features he requires. - I personally am not competent to fix most of the problems I or somebody else come across - even when they reside in relatively simple parts of the TeXmacs code. I would contribute more if I had a better understanding of the TeXmacs code base but I would have to put in a significant amount of work to achieve a better understanding. Probably a number of other people are in a similar position. - To reliably fix a bug some time after it is reported, we would, in the end, need more people who actively fix issues. (A trivial observation.) Solving these Problems: - Active maintenance of the Savannah bug tracker. This includes: ensuring that the bugs mentioned on the ML end up in the tracker and confirming/assigning the bugs entered there. - Regular testing of TeXmacs. Organization of Bug-Hunting sessions. - Recruiting more people who can actually fix bugs. There may be two roads to success here. * Better education of potential TeXmacs hackers. * Monetary incentives. As part of the association? As bounties? Making TeXmacs more accessible (to potential hackers): - Split TeXmacs into well-defined components (type-setter, gui, style-sheets, converters, PS-device,...) with well-defined interfaces that can be understood one at a time. - Better documentation. Both high-level documents describing the architecture as well as low level source code comments. I personally am willing to contribute time as well as money to this endeavor. E.g. I could take charge of the maintenance of the issue tracker. The componentization of TeXmacs is of particular interest to me, but I do not feel competent to "just go ahead" and try to do it. Now, this was a long mail and "just my 2 cents". Thanks for bearing with me. Felix _______________________________________________ Texmacs-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
