Hi fellow developers,
before reading what follows please take into account that I am awake
for more
than 20 hours, I have traveled thousands of kilometers (or miles), exchanged
planes, ran through different terminals and check-ins to find a delayed
flight, and on arrival had a class with 40 students. :-)
Before this falls into any self-commiseration or a whimsical exercise I
should say that I am quite happy and just need to rest to recover. I fell on
the other hand that timing is critical and that this is a good time for this
message.
I skip emoticons in most parts of the message. If in doubt please do
not
hesitate and ask.
Prelude:
For those who never came to a meeting some of the decisions seem
literally
alien. I remember what I felt in the first two meetings, the problems we had
then we have them now. There are things that seem natural if you are there
that are strange if you have never been there. Take the testimony of Angus,
Jean-Marc, Michael or Martin, if you don't believe it.
It is not a life-time changing experience but it sounds interesting, I
still
remember the remarks from Martin last year in Paris, and Martin is not a
random teenager with no life experience. :-)
So with this said I look forward to see Georg (who seems to always read
my
mind when it comes to lyx2lyx), Abdel (to pay you a beverage for qt4 work) or
Jürgen S. for all the work so usefully done in several areas of LyX. If I
have not thanked you how much you helped me in my thesis I take this change.
I am not trying to remember or forget anyone in particular, it was
interesting to meet Charles De Miramon (I hope I get the name right) last
year in Paris. Hello John, Enrico, Bo, Peter, Edwin, Uwe and ... (please fill
your name if I forgot, I apologise for that) we are waiting you in the next
meeting.
I know that Jürgen and Asger are two "enfant terribles" (as well as
extremely
fond and tender fathers but that this not relevant in this discussion), from
whom I like to hear their opinions, if not for more then to avoid
the "in-breading" of the ideas developed in this mailing list. This does not
means that I agree always with them, but it is nice to hear fresh new or old
ideas. :-)
It is as well very difficult to appreciate the wit and humour of Lars,
Jean-Marc or André unless you know them personally. The same applies to Angus
and Martin's elegance of thought. I have learned a lot with all of you guys
during those meetings.
Email is such a terrible medium of transmition, and even worse, for a
group
where everyone knows each one for several years when communicating with
unattended developers. Jokes that are a hit when in person become diluted and
fuzzy when written. (For a bitter exchange see today's thread about RPM on
Fedora Extras, I am a Fedora Maintainer that is why I follow this case, as an
example of something that should never happen on LyX).
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.
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.
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).
My proposal follows that coming from the meeting to enter a period of
feature
freeze, that is no more features are allowed at this point. Our goal now
should be to stabilise the new changes and to coordinate with the present
stable branch to make the transition the smoothest possible for the new
stable release (1.5 when released).
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. We had xforms, in maintenance mode, but with some technical
problems of its own (the transition to unicode would be harsh on it). Gtk
seems interesting but it still needs some work before being feature complete.
As seen from the discussions from Abdel and Lars we seem to be near
from a
time where frontends will be loaded on demand.
This seems to mean that branches are good places for frontend that not
yet
complete and active.
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.
1.5 Features:
- Unicode / new 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 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?
Notice that missing features are OK. By absurd imagine that sessions code is
ready only for the first window and not for the others. This is acceptable
for an alpha release.
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. That
is Monday, 13 November 2006.
From this experience we will decide on the next step, another alpha release or
the first release candidate.
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. :-)
It is a matter of priority:
Example:
Does the fix prevents old documents from being typeset correctly?
This deserves a good look until the last day of testing.
Another example:
Does the withdrawing of a toolbar has the same treatment?
No, if the fix is small and well understood it should go in doing the testing
phase. If we are in a deep release mode this fix would be delayed to the next
stable release (1.5.1 in this case).
This means that the criteria to commit fixes will become more and more
stringent as the time passes. I will give further details as times goes by.
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.
Postface:
This message ended longer than I intended to. I don't pretend to have all the
answer neither in real life or here, you feedback is welcome and vital.
Thank you for reading until this point. :-)
Best regards,
--
José Abílio
