[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Stabilization of TeXmacs
Re: [Texmacs-dev] Stabilization of TeXmacs
Fri, 01 Dec 2006 15:45:03 +0100
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:
> >- 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.
> >- 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
> > 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.
> > * 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
> >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
> 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
> >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
|[Prev in Thread]
||[Next in Thread]|
- Re: [Texmacs-dev] Stabilization of TeXmacs,
Felix Breuer <=