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
address@hidden
http://lists.gnu.org/mailman/listinfo/texmacs-dev