On Tuesday 24 October 2006 8:30 pm, Georg Baum wrote: > > No. IMO it was a mistake to skip the "let those who care keep it working in > svn while others ignore it" phase. But now the baby is already thrown out > and dead. I was willing to keep the qt3 frontend working as long as that > would not require too much work, because it was mature and I believe it > would have been useful for a number of people. That worked quite well > during the last weeks, because Abdel's qt4 code was well written and I > could adapt it quickly to qt3. I am not willing to bring it back to life, > resurrecting all the many bits that are required for that would be far too > much effort.
OK. I drop this proposal. :-) > > Georg you have mentioned other changes, what are they? > > Several bugs in bugzilla with the fileformat keyword: > http://bugzilla.lyx.org/buglist.cgi?short_desc_type=allwordssubstr&short_de >sc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubst >r&bug_file_loc=&keywords_type=allwords&keywords=fileformat&bug_status=UNCONF >IRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED Most of them > are simple, and we can only fix these for a major release. Some of them > were postponed from 1.2.0 to 1.3.0 to to 1.4.0 to 1.5.0, because they were > not allowed to be fixed in freeze mode because of the freeze, and were not > allowed to be fixed after the .0 releaswe because of the file format > change. At least the easy ones should be fixed, otherwise they will stay > open forever. I don't have patches for these, and it is unlikely I'll work > on them, but I really think it is important to fix them. I propose to leave that for 1.6, we will rework the file format in such a way that working with this now would mean duplicate work. > Then I have more or less finished support for esint that I need for my > thesis: http://bugzilla.lyx.org/show_bug.cgi?id=2108 > Current support for integrals other than \int in LyX is a mess. symbols > from several not matching fonts are used. Do you have a patch for this? I would like to consider it if yes. > Then I think it would be a very bad idea to not put the nomencl inset in > 1.5.0. It is finished, I have a few minor complaints that I will send the > next week when Ugras is back from his holidays, but these issues can > easily be fixed. lyx2lyx conversion is also almost finished, and finally > there is no risk to break existing stuff. OK. > Another important point is complete support for \xymatrix: > http://bugzilla.lyx.org/show_bug.cgi?id=2238 Does that patch there works? > Since it is not possible in mathed to enter known commands as ERT you can > not use everything that \xymatrix offers. Prof. Gumm complained some time > ago about this, and he was right. After a hard fight I was able to commit > a fix during the 1.4.0 freeze that brought back at least the level of > support that 1.3.x had. This was a regression, the fix was safe and indeed > so far no bugs resulting from this were discovered, so it was IMO no > question to put it in. This is an example for a exhausting discussion I > will no longer take part in. > As a first step it would be enough if mathed was able to read and write all > \xymatrix arguments correctly. Then you can e.g. write the formula as text > and convert it to math, or correctly import existing documents with > tex2lyx. I already haven an almost working implementation of this first > step. How much work is required to have this in a state to be present in alpha 1 - (called Ruby)? > > Some of your changes in the 1.4 branch seem quite interesting. > > The image cache works well now. The only thing that would be needed before > it can be put in trunk are some lyxrc options for cache size, cache file > lifetime and code that uses these options to cleanup the cache. I would welcome a lyxrc only patch for now. Working on a document with more than 100 figures I can feel your pain. :-) > The navigation across child documents is also stable, but it has the > problem that it causes all child documents to be loaded if you open the > master, and this can take some time. Either we need to speed up loading of > a document (actually I don't know why it is so slow), or we need to > implement loading of child documents in the background. This would be nice. I assume the code is simple, right? > I do not want to push either of these into 1.5.0, but if somebody has a > good idea how to solve the remaining problems it may be sensible to > include one or both. I implemented the first for large documents with many > images, and the second one because it is essential for navigating in my > thesis. Both are applications where LyX is supposed to make the life > easier. That is the only reason why I admit to consider them. That is also, IMHO, one of the areas where we do not have rival (at least for now). If I give green light for this what needs to be done? What help do you need from others? > The rest in my branch is either already in trunk, bug fixing stuff or > incomplete. OK. > > I would like to have a tentative date for a pre-release. How much time do > > the > > > respective owners expect to need to have the new features in such a state > > that they can be presented to users without having them screaming away? > > This week I will only finish the command inset lyx2lyx stuff. I don't know > yet how much LyX work I will do during the next weeks, but it will > probably not be more than putting in what I already have. Therefore feel > free to ignore everything I wrote above. What I know for sure is that I > don't have the energy to participate in any fight that might come. I don't have any problem with fights, as long as the outcome is productive. :-) > > I trust in your judgement to decide on what is this state. On the other > > hand > > > we need a quick release, or else all the flurry in the mailing list was > > useless, so I suggest a deadline for the alpha release of three weeks. > > I don't think a quick release is that important. If you would do this alpha > release, and then add a phase of two or three weeks of fixing known bugs > that are already in 1.4 (and of course all that appear in the alpha > release), then this delay will be very worthwhile. I would imagine that > not only safe fixes are allowed in this phase, but also some mildly risky > ones. After that phase the rules would be stricter. I don't think that you first sentence agrees with others in this paragraph. :-) When I say that we need quick release I am not speaking about Christmas, at least not in the LyX sense. ;-) > Without such a phase where everybody is actively fixing bugs from time to > time I see no chance to decrease the number of open bugs. The large number > of open bugs is again something that unnecessarily eats resources. > Bugzilla has several bugs that were retargeted several times back and > forth, where each retargeting is connected to some discussion, often > involving Uwe who wants to have a bug fixed soon (which is of course > understandable), and on the other side Jean-Marc or sometimes me who do > not want to delay a release which is already overdue. > I can only recommend to anybody who does not do it already to have a look > at the changes in bugzilla from time to time. You can learn a lot there. A fair advice. :-) >> This is my sole prerogative as release manager, I will listen to what >> other >> have to say but the last word is mine. If necessary I will revert commits >> if I find them inappropriate, I like to smile but if necessary I can frown >> if necessary. > > If you need to revert commits we have a big communication and/or trust > problem. Probably, or sometimes just a big misunderstanding. It is important though that everyone knows about this. Following one of the python's motto: $ python -c 'import this' ... Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. ... Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. ... Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. ... > José, thanks for this message. My answer became longer than intended as > well. Thanks. > Georg -- José Abílio
