On 5/12/10, Per Inge Mathisen wrote:
2.3.0 has so far seemed like a pretty solid release, and there is no
desperate need for a 2.3.1 yet. Discussions of new features seem to
have moved to trunk. How about we try to schedule a 2.3.1 bug-fix-only
release for mid-June?
We are a bit passed the 'bug-fix only' mantra, since some of the stuff
that is currently in svn/2.3 are not really bug fixes per se, but that
release schedule sounds OK.
Trunk seems rather stable at the moment, and branching it as a
possible release point before merging any of the big 3 feature
branches may be a good idea. One idea is to branch is to a codename
branch, start merging the feature branches, and depending on how
stable or unstable trunk becomes after that, either proceed to release
from the codename branch, or from trunk after the merges (nuking the
codename branch).
While I haven't personally tested trunk in a long time, Zarel
mentioned that the pathwalking is broken.
Yeah, I know there is a ticket
(http://developer.wz2100.net/ticket/1649) but I haven't really had the
time to look into this more.
The trunk test builds that we threw up haven't really gotten any
feedback at all, and with the new web site style, it isn't exactly
easy to change things, since we rely on one person, and the
information on how to fix/change it, hasn't exactly been forthcoming.
We have 3 big feature branches that we need to merge before
accelerating bitrot makes merging even more difficult. The merge
priority that we have discussed earlier for the big 3 feature branches
is 1) Qt branch, 2) newnet, and 3) lua. Last comes last because it
seems most unfinished yet, and Qt branch first because it has seemed
closest to completion and has the most developers familiar with the
new code. However, we can easily change the merge order - there are no
interdependencies between them.
I think we need to clear up some things about these branches.
1) Qt.
- we don't really have anyone that is well versed in Qt for the current issues.
Those are, on the mac, the input state is swapped from our normal
routines. Currently, we can hack around that, however, we still have
text issues, and the fact that we can't get key map screen to show
Ctrl or Alt like it does on windows / linux for whatever reason.
AFAIK, Alt should work like it does on windows / linux, but it doesn't
show Alt + letter like it should.
The Main menu / in game menus suffer from a state conflict. That is,
when we set modes, (pie_SetRendMode() pie_SetTranslucencyMode()), it
looks like we are conflicting with the way Qt is handling the
window/widget. Qt suggest to use
beginNativePainting()/endNativePainting(), but that causes a big
performance hit, and didn't really fix anything when I tried some
tests with that.
While experimenting with Qt Designer for a new lobby screen, I don't
see a easy way to match the current color scheme / style of warzone,
and if we go this route, the issue then becomes how easy is it to
maintain?
I have not done any svg tests, so unsure how smooth this will go.
As of right now, I can only think of one advantage to Qt, and that is
for the hardware colored cursor support.
The lack of a dedicated mac Qt expert person to help us trying to
fix this doesn't make things easy, and it gets annoying, since we must
waste more time digging into tons of docs hoping to find out the
cause, then waiting for feedback.
With SDL, we are pretty much at, it just works for all the
platforms, so people can concentrate on other issues at hand.
2) newnet.
Besides the problems listed in
http://developer.wz2100.net/ticket/1786, I don't really understand the
main reason for having such a high requirement for precision. (I
haven't really looked at the code either)
Compiler issues are the main problem here, though, I haven't really
played with it enough to see if it has other problems.
We can't release test builds of this until that is fixed, and we won't
merge to trunk, until we know it works as it should.
3) Lua.
The last I recall, the state of lua was about 50-55% done, and the
forum thread : http://forums.wz2100.net/viewtopic.php?f=35t=4733
shows that the conversion script is buggy / broken for some things.
We don't really have anyone who is a lua expert either (since Gerard
was about the closest thing we had, and he isn't around much), so that
is slowing things down drastically as well.
4)Beta widget
Yeah, I know this wasn't mentioned, but, it appears there is lots of
confusion of the shape this is in. It uses deprecated lib(s), and
would add lots more dependencies, and trying to compile those
deprecated lib(s) on anything but unix is a huge PITA.
It never really got past the (pre) alpha stage, before it fell by the wayside.
The thinking to revive this was to use Qt for the SVG routines, but,
there have been no tests at all, so we are not even sure if this would
be a good move or not. Everything is in theory, it should work.
If we proceed to
