On Mon, Jul 14, 2003 at 02:33:24PM +0200, Michael Schmitt wrote: > Hello everybody, > > as Andre pointed out last week, it is likely that the rework of the LyX > kernel will continue for many more months. I really appreciate what > Andre has done so far
Oh, the biggest chunk in 1.4.0cvs so far is the paragraph & rowlist sanitizing. Not my doing... > and what he will hopefully do in the future. [I am pretty sure I have to reduce LyX related activities from the end of the year on. I'll lose my job (project runs out, no extension possible, no other projects in sight...) and there are 'family matters' looming.] > However, we should also think about a roadmap for 1.4.0 again. 1.4.0cvs > already offers a lot of nice new features and it would be a pity if the > users had to wait until next year. I remember saying something like "even if we had a feature freeze right now and only tried to make everything work again, 1.4.0 won't be out before Christmas". [And even more annoying: All this patch work will be lost in case we'll have the cleanup some day later...] > Would it be possible to suspend the kernel rewrite at some clearly > defined point? Say, after the metrics-draw split? Probably. But it is hard to tell where the 'metrics-draw split' ends and where general LyXText/InsetText cleanup begins. Alone in the discussion about such thing we will waste a lot of energy. > Or do we have to fix _everything_ before the kernel becomes stable > again? No. But quite a bit... We could e.g. leave out the 'centralized cursor' even if that would mean no 'inset unification' in 1.4. We could leave out 'InsetEnvironment' related stuff as this is a new feature. We could leave out 'consolidation of InsetText and main text' as it 'used to be like that'... > What are the tasks that must be performed before we reach the > nearest point at which we are able to release 1.4.0? 'Update removal' plus the missing parts of 'Two phase drawing' (i.e. the metrics/draw split) should be a safe bet. The first should bring robustness, the second is needed to make the first happen. > Last Friday, John convinced me to work through all the open (not > verified) bugzilla entries (472 as of today) and check whether they > are still relevant. Most bug reports are independent from the current > kernel rewrite and there are many small(er) issues that could be fixed > while Andre is doing his magic. Maybe we should start to minimize the > number of open bugs to shorten the code freeze period later? I certainly don't object. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
