Re: [Texmacs-dev] Stabilization of TeXmacs

[Felix Breuer]

Hi Henri,

thanks for your response! I have started looking at the issues in the
tracker. I still have to become a "project member" on Savannah, so that
I can actually tag bugs. (I asked Joris about it just now.)

Regarding the modularization of TeXmacs: it would be great if it were
indeed possible to achieve something right away. What "split(s)" do you
think most likely to be feasible in the short term?

Best,
Felix

On Thu, 2006-11-30 at 12:48 +0100, Henri Lesourd wrote:
> 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
>