Months ago (on 3 Jan), Marko Lindqvist wrote:
>  Now already evaluating this list with beta1 in mind (mainly because
> network protocol and datafile format freezes are needed before beta)

Hello, yes. I need to get on top of 2.5.0-beta1. Sorry for the lack of
activity on that.

I haven't started making a release note, which was the process that
drove getting to release quality for 2.4 (working out how to describe
the new features => reverse-engineering documentation => raising and
fixing bugs found while testing my understanding).

Some time ago, I think you offered to provide a summary of the major
changes as a starting point for the release note. If that offer's still
open, I'd like to take it up. I expect I'll still be doing my
ultra-complete trawl through svn logs, but perhaps having a summary of
the big themes rather than reverse-engineering them will expedite the

>>> Here's list of features I think should make it to 2.5 (not necessarily
>>> complete - I may have forgotten something) I hope other maintainers to
>>> reply with their own additions and comments to the list.
>>> patch #4190: Split translations to multiple po-files
>>> If we are going to add information about what translation domain
>>> translations about the nation should be fetched to the rulesets, it
>>> must be done before datafile format freeze.
>>  This has been implemented to the extend I dreamed about, but the
>> ticket has been given to jtn to further evaluate what more is needed.
>  ?

I don't now expect to implement anything like the full madness of
<>, but there's still a
minimal level of work required in defining a suitable workflow for
importing translations, updating freeciv.pot, updating po-files, etc in
a world with multiple translation domains.
(This is quite high-priority, because it's indirectly retarding
translator work on S2_5 and later.)

>>> Qt-client
>>> Qt-client is coming along so well that it would be a shame not to get it
>>> to "supported client" status in 2.5. Mir3x probably keeps on working on
>>> Qt4 based version.
>  Qt5 now.

I haven't been keeping on top of the Qt client. Is there a description
of the major missing features at the moment? Perhaps we need a

In the absence of that knowledge, this feels a bit ambitious to me. We
still have work getting Gtk3 client up to "supported client" status IMO
(see below).

>>  New Qt-client related item is that I'd want freeciv-mp-qt to be in
>> good enough shape to be used in those installations that use
>> Qt-client, so one does not need to mix gtk-based freeciv-mp-gtk[23] to
>> Qt system.
>> I'm working on this.
> Mostly done


>>> patch #3448: "Nation sets": allow set of nations that will ever appear
>>> in-game to be chosen
>>> Affects both network protocol and ruleset format, I think.
>>  There has been some progress.
>  If I have understood correctly all that is missing is support from
> some of the clients. That shouldn't stop us from going toward beta (no
> network protocol issues, I assume)

That's about right. With the Gtk clients, I consider the feature

However, I'm keen that every supported client should have a UI for this
feature, even if a minimal one. Otherwise, all the nations maintainers'
hard work on the "extended" nation set becomes completely invisible to
casual users of that client, which was something I explicitly wanted to
avoid when creating two tiers of nations.

Help in this area would be appreciated. In particular, I've not done any
Qt hacking, so if someone else could add support to the Qt client, that
would be great.
<> "Qt client support for nation sets"

The SDL client should also have support. I'd be content with minimal
support to start with (add a drop-down, but if you change it the nations
dialog pops down -- this would save some fiddly widget-wrangling).
<> "SDL client support for nation sets"

(I'm willing to let the Xaw client slide.)

>>> patch #4088: Included dependencies of sdl-client
>>  SDL_gfx has been handled.
>>  SDL_ttf remains.
>   There's patches about SDL_ttf side too, so this can be closed soon.

<> closed => done?

>>> bug #17887: Tech prerequisites misdisplayed in help if root_req set
>>> For a long time this was release blocker for 2.4, until we just worked
>>> around the need to get it done for 2.4. I hope we will not be forced to
>>> do that again with 2.5.
>>  No progress.
>  Working on that area. TRUNK is getting bigger rewrite, but easy fixes
> will go to stable branches too. Those do not need protocol changes, so
> this is not blocking beta. It's quite ok for this to wait to beta2.

Haven't dug into where this got up to. (For 2.4.2 I claimed that
"problems remain" in this area, but in fact I can't point to anything
specific; and I don't know whether 2.5 is actually better.)

Would we now in theory be able to add the root_reqs back into the
experimental ruleset while keeping it usable, if we wanted to?

>>> gtk3-client as default
>>> Gtk3-client is default client in 2.5. Its remaining issues should be
>>> resolved that it would be worthy of that status.
>>  There's windows version available now, but it has performance issues.
>  It would be nice to get it tested in betas, but not going to put
> beta1 to who-knows-how-long wait for this. Blocking final 2.5.0,
> though.

<> lists possible blockers to Gtk3 as default
client. Many are still open.

Not on the list is improvement of the Gtk3 custom theme, but that's
actually what's been stopping me from using the Gtk3 client more myself,
or recommending it to anyone else.
Right now I think it's much uglier than the Gtk2 theme, although that's
subjective. It certainly takes up much more screen space at the moment.

Should create a ticket. The help of someone who knows how to hack Gtk3
theming would be very helpful here.

(Of course we could make the Freeciv theme not the default, if we don't
make progess on this.)

>>> Missing art: bug #20536, bug #20032, bug #20031, bug #20029, bug #20030

Some fixed; bug #20536, bug #20032, bug #20029, part of bug #20030

>>  About the schedule:
>>  1) Would targeting 01-Mar-14 as datafile format freeze be ok for everyone?
>>  If yes, 2) Would targeting network protocol freeze about half a month
>> later (15-Mar-14) be ok?

I don't have anything outstanding that I *know* will need network
protocol changes -- but I'm not on top of the release polishing that
needs doing. Of course we can use capabilities if we have to.

>>  If yes, 3) Would targeting beta1 couple of weeks later be ok?

That would be about now. I think we're not ready for beta1 yet. I'd like
to have a better grasp on what features are in it and their current
state first.

We also need to scrub the bugs tagged as "2.5.0". I'm sure I raised some
fairly major ones in that category which I didn't immediately
investigate, for the sake of not getting distracted from whatever I was
doing at the time; I don't know which have since been fixed. There could
be some in there severe enough to block beta1.

Freeciv-dev mailing list

Reply via email to