[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Stabilization of TeXmacs

From: Bruno Loff
Subject: Re: [Texmacs-dev] Stabilization of TeXmacs
Date: Thu, 30 Nov 2006 08:14:13 +0000

Although this is not exactly what Felix is saying, I do get the
feeling that TeXmacs could some day be usable software, but still

It might be nice for TeXmacs if a (a few?) Google summer of code
project(s) would contribute towards making TeXmacs a more finishes
application and a more "changeable" application. Documentation for the
source, the structure of the program, etc would sure help people
contribute for TeXmacs. I personally never managed to understand
_where_ stuff is in the code in order to change something that was
supposed to be simple.


On 11/29/06, Felix Breuer <address@hidden> wrote:
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:

- 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.

- 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.


Texmacs-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]