Thanks for the explanations, José. I think a rationale like this instead of
all the whine/cheese/omelett allegories would have helped a lot.
José Matos wrote:
> fill your name if I forgot, I apologise for that) we are waiting you in the
> next meeting.
It's a time problem, really.
> Practice:
> As a release manager I am a firm believer in the principle of "releasing
> earlier, release often", I also believe that as a project we will only
> survive and thrive if we present a stable product to our users as well to
> (prospective) future developers. No one will waste their time if the
> developing platform is not stable.
Agreed.
> For the project it is good to have a goal and to focus on it. The goal
> for
> 1.5, already decided in the last meeting, is unicode.
Which is a good an overdue decision (just to clarify that I am not and was
never against this move, as opposed to excluding the possibility to support
stable inputenc encodings), and I appreciate all the work that was put in
there, especially by Lars.
> Mixing the two previous paragraphs, that means that we should release a
> product as soon as possible when certain requirements are met, those
> requirements are:
> - to have a stable frontend;
> - no (known) regressions are allowed against old documents, if a
> document
> works for 1.4 it should work as well in 1.5 without any change from user.
> - The last requirement does not applies vice-versa, it is possible to
> have
> a document that works for 1.5 that when backported does not work for 1.4, I
> will try to fix those cases but they are not our priority (back-port is a
> convenience).
Agreed. However (and that was what I tried to point out),
\usepackage[utf8]{inputenc} only would have been such a regression, and I am
very sure that lots of documents from 1.4 wouldn't have worked in 1.5 without
any change from the user. Some would not even have worked without exporting,
editing and latexing manually (I've listed some of the more frequent
packages).
> Frontends:
> We need to have a default frontend, that should be the most complete and
> with an active comunity of developers around it. Reading the mailing list
> in the present year that frontend seems to be qt4, with qt3 being in
> maintenance mode mostly.
Yes, but of course also because qt4 was a new (and ambitious) contribution,
while qt3 was mainly matured. Personally, I did only fix some bugs, because I
am quite satisfied with the qt3 frontend as is.
> 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?
> For 1.6 I propose to remove qt3 and completely have it superseeded by
> qt4.
I would welcome it, yes (and would agree on dropping it as soon as the 1.6
work begins). However, if I'm the only one, then let it rest.
> 1.5 Features:
> - Unicode / new encodings.
I'd rather say: Unicode and the _old_ (matured) (LaTeX input)encodings ;-)
> - Multiple windows.
> - Change tracking
> - Multiple windows.
> - Sessions
>
> - What am I missing more?
> Georg you have mentioned other changes, what are they?
> Some of your changes in the 1.4 branch seem quite interesting.
I think so, too, especially the picture cache. But as I understand it, Georg
thinks it's not mature yet.
I think it's rather unfortunate that the freeze affects Ugras' (and Georg's)
nomencl work. Ugras has invested a lot of time in the insetcommand in order
to get his pet projects, nomencl and splitidx, in. While the latter is still
under development (and thus clearly a candidate for 1.6), the former has been
proposed weeks ago already.
Personally, I have nothing in the pipe which cannot wait. I am a bit short in
time ATM, but I try to help polishing the qt4 dialogs and testing the
inputenc work.
> Questions:
>
> Q: Does Denmark agree that bug fixes are welcome at all times?
>
> A: I am not Denmark but I will answer this. The role to follow here is the
> stable series. Not all fixes are welcome at all times, special at the last
> day or minute. :-)
I have proposed some fixes for 1.4 actually, which are still to be reviewed by
Jean-Marc. But of course, fixes for 1.4 do only make sense if they can go
into 1.5 as well (one of them, a duplicate checker for labels, might not pass
your criteria).
> Thank you for reading until this point. :-)
Thanks for the explanations.
> Best regards,
Jürgen
