On 6 April 2014 17:43, Jacob Nevins
<0jacobnk.fc...@chiark.greenend.org.uk> wrote:
> 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.

 Just give me week or two.

>>>> 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
> <http://gna.org/patch/download.php?file_id=19163>, 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
> metaticket?

 We have metaticket patch #4417, but it doesn't have much content - I
have had only a couple short sessions with Qt-client so not explored
what it absolutely still needs.

> 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).

 gtk3-client should not only be "supported", but even "default"...
Remember that both "sdl" and even "xaw" are supported clients... But
you're right, and I never meant that this should be a blocker for 2.5
(if Mir3x has not time to work on this, I don't anybody else to), just
something that we might get.

>>>  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
> Done?

 I'm not completely satisfied with the quality.

>>>> 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
> complete.
> 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.
> <http://gna.org/patch/?4350> "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).
> <http://gna.org/patch/?4351> "SDL client support for nation sets"

 I have this in my personal TODO notes in the roadmap of sdl2-client
development (I expect to learn more of the sdl(2)-client widget code
by doing other tasks before trying to tackle this)

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

 It's soon time to do our regular "do we really still need xaw-client
maintained" discussion, I think. Those who insist it must be kept are
not showing it the love accordingly.

>>>> 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.
> <http://gna.org/patch/?4386> 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.)

 The only user-visible difference between S2_4 and S2_5 I can remember
from top-of-my-head is that S2_5 has more colors in tech tree - S2_4
datafile format freeze prevented requiring new color definitions,
meaning some colors that ought to be distinct are the same.

> 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?

 It was never removed from branches other than S2_4 (one difficullty
in writing release notes is to know what has *not* changed in S2_5 as
in S2_4)

>>>> 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.
> <http://gna.org/task/?7760> 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.

 Try using Debian Testing. Here only some minor parts of gtk2-client
theme work, but gtk3-client one seems about complete. It used to be
the other way around until some gtk updates.

> 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
> remain.
>>>  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.

 The only reason to freeze network protocol would be possibility to
already provide builds that are compatible with final release. Has to
be at least 2 weeks before beta1, though.

>>>  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.

 Yes, that might reveal some critical problems.

> 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.

 - ML

Freeciv-dev mailing list

Reply via email to