Re: [Texmacs-dev] Stabilization of TeXmacs

[Henri Lesourd]

Felix Breuer wrote:

> 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
>
>  
The big weakness is in bug fixing, currently, and this is
where the hard part of the problem is, in fact.

More generally, the problem is that depending on the kinds
of bugs / features that need to be implemented, one needs
to prioritize according to the current state of the implementation.

Namely, there are two main things :
- There are things that are more important than others ;
- There are things that are harder to do than others ;

And my opinion is that on the one hand, what is really needed
is more people that can hack, and on the other hand, the current
state of the implementation is way too monolithic to allow a
large team of loosely coupled people working together (a chief
example of that being the way people work in the Python community,
for example).


> 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.
I don't think it changes a lot the nature of the situation. In any case,
what needs to be done is read the bug reports, classify and prioritize
problems, do a tasklist accordingly, and last but not least, of course,
afterwards, perform the operations that are on the task list.


> - The testing of TeXmacs is no coordinated effort. Bugs are found
>  when a user stumbles upon them.
Difficult to do otherwise.


> - There is no repository of test-case documents, except the ML archives.
>
>  
Very true : small, minimized tests that exhibit clearly the behaviour of
a bug are an extremely important thing : without this, you cannot reliably
communicate the information about bugs. Efforts in this direction are
never a waste of time, they are always an improvement.


> Fixing:
> - Nobody seems to feel responsible for the Savannah Bug-Tracker. The bugs
>  entered there appear to be ignored.
Its perhaps true that we are a little bit late on this one...


> - 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.
>  
The thing is that we need to focus on the more low-level/technical
issues, all the more because work on TeXmacs is only part-time.


> - 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.
One useful thing has been decided is that I will start writing
documentation for TeXmacs developers. Currently, as far
as developing inside/with TeXmacs, lots of things are completely
undocumented, and is is clearly a bottleneck (that we can
remove). It was not really possible to do this before, because
previously, too much things in the APIs were unstable.


> - 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.)
>
>
>  
I could not agree more. It is the main problem, in my opinion.

Ultimately, a real solution to this problem should contain :
1/ A good hacking documentation ;
2/ More modularization of the software (but for this one,
   it is a long way to really achieve).


> 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.
>  
It would be nice.


> - Regular testing of TeXmacs. Organization of Bug-Hunting sessions.
Nice, but it costs time...


> - Recruiting more people who can actually fix bugs.
Yes, that's what we should try to do, but it seems
that doing that in a really meaningful way takes
some time (writing the documentation, looking
at what are the stable parts of the code and what
is not, etc.).


> There may be two roads to
>  success here.
>  * Better education of potential TeXmacs hackers.
Yes.


>  * Monetary incentives. As part of the association? As bounties?
>
>  
It's hard to make it work well, because to become really
efficient, you need a long time investment in the software.

Currently, as far as money is concerned, finding ways to
provide jobs for people around TeXmacs is a much more
reliable solution.

Or either, there are also very competent people that do
things in TeXmacs just because they are interested in.

But if you look closely, you discover that very often,
they can afford it because somehow, one part of their
main activity is close to TeXmacs.

Is there a silver bullet ?


> 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.
I definitely agree that this one is important. But it's long to do, and
currently, the tasklist for this year is already full, although some of
the tasks can be considered as going in that direction, because they
are likely to lead us to make the source code simpler.


> - Better documentation. Both high-level documents describing the architecture as
>  well as low level source code comments.
Currently, what is underway is defining an API for
the Scheme in TeXmacs. As far as the source code
is concerned, people should read it, comments are
often not a very efficient way to go. Helping people
to **do** things is much better, all the more because
it leads to revealing much more quickly bugs, design
problems, etc.

Indeed, this is the big, hidden root cause of the
bugs / problems, etc. your mail is about : when
a new feature is implemented, too often, we cannot
perform an extensive testing, because we are only
implementing it for ourselves / for one current purpose.
As you cited, and as Joris puts it, he "rather wants
to implement the new features he requires". But
it cannot be considered as good, because this way,
it is crystal clear that the amount of experience/information
we can collect about one feature is much smaller
than what you would get if several people were
in the same time trying to use the new feature in
their own programs. On the other hand, of course,
this situation is comfortable, it allows for more
time reflecting about the design. But...


> 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.
That would be great.

The main question remains : who are the people that
can fix the bugs ? On the one hand, there are bugs that
need long explanations (i.e., problems in the C++, or
even worst, design problems), but as far as I remember
the bugs if the issue tracker, there are also lots of bugs,
for example, bugs in the TeXmacs stylesheets, or in the
behaviour of some markup that could be solved without
a detailed knowledge of the TeXmacs internals, but rather,
only with knowkledge about the stylesheet language, and
perhaps a little bit of Scheme limited to what is necessary
to understand what's going on with the menus.

Thus it seems to me that the first tasks to perform in this
respect are :

1/ Classifying the bugs, in particular, for each bug,
   indentifying precisely what kind of knowledge
   is necessary ;

2/ Once we have this information, allocating the
   bugs among a bunch of people becomes feasible,
   and if necessary, we can even provide them with
   the bugs **and** the information to tell them the
   place where they should look in the documentation
   for finding the knowledge they need to solve the
   bug.

We would thus divide the bug fixing task into
the following subtasks :
<<
a/ bug reports ;
b/ bug classification, in particular, annotating the bugs
   with precisely what kind of knowledge you need to
   solve them [to me, it is highly interesting to observe
   that right now, now that I'm thinking about that, no
   bug tracker really offers such a feature, although for
   sure, knowing what knowledge you need is a mandatory
   ability in any kind of problem-solving] ;
c/ bug allocation ;
d/ bug fixing ;
e/ bug fixes evaluation (accepted / rejected / some
   changes are necessary before the fix can be accepted) ;
>>


> 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.
We should definitely try to have a look at what could
be done right now, one of these days.


In any case, thank you very much for your valuable
input ; it definitely made my mind running ;-).


Best, Henri