Am Dienstag, 24. Oktober 2006 01:07 schrieb José Matos: > Again following the previous reasoning, I propose the following, we should > revert the removal of qt3 from lyx 1.5, now that we have manage to keep it > until the feature freeze it would look like throwing the baby with the water > (following one previous analogy of Angus on this list). > > This should only be done on the condition that there are people interested in > having it on shape for 1.5 release. Georg and Jürgen do I assume correctly > that you would welcome this change?
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. > 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_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=fileformat&bug_status=UNCONFIRMED&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. 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. 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. Another important point is complete support for \xymatrix: http://bugzilla.lyx.org/show_bug.cgi?id=2238 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. > 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. 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. 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. The rest in my branch is either already in trunk, bug fixing stuff or incomplete. > 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 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. 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. > 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. José, thanks for this message. My answer became longer than intended as well. Georg
