[Top][All Lists]

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

Re: [Texmacs-dev] Stabilization of TeXmacs

From: Felix Breuer
Subject: Re: [Texmacs-dev] Stabilization of TeXmacs
Date: Fri, 01 Dec 2006 15:45:03 +0100

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?


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

reply via email to

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