Bug#766185: freeciv-client-gtk: Removal of GTK+3 client

Markus Koschany apo at gambaru.de
Tue Oct 21 12:14:04 UTC 2014


Package: freeciv-client-gtk
Version: 2.4.3-2
Severity: normal

I think filing a bug report against freeciv-client-gtk is now the best
way to discuss this change in public, otherwise too much information
will get lost in private conversations and nobody does understand why
decisions have been made.

Summary:

The upstream developers of Freeciv request to stop packaging the GTK+ 3
client because recent versions of GTK+ 3 libraries apparently broke
certain functionality which is vital to play and enjoy the game.

TL;DR

Three points of view:

* We either view Debian's convenient support for different Freeciv
  clients as a service for players and expect them to read the package
  description before playing the game. We continue the current practice
  and ship other clients than GTK+ 2 in separate packages and keep the
  GTK+ 3 client or

* we stop providing multiple clients and force players to use the GTK+
  2 client which seems is the only one that is really supported
  upstream. This is a medium term solution since it requires disruptive
  changes.

* We drop the GTK+ 3 client immediately, remove the Xaw client for
  Jessie+1 and only support the GTK+ 2 client and the SDL client and
  only introduce new clients if they are maintained and supported
  upstream.

I we tend more to point two then we should remove the GTK+ 3 client
immediately but we should also consider to remove the Xaw and SDL client
as well since they are also not on a par with the GTK+ 2 client.
All in all that would reduce the maintenance burden significantly. Point
three is a compromise.


I'm replying in-line to the last e-mail that I received from Jacob
Nevins (upstream developer of Freeciv)


>> On 19.10.2014 12:06, Jacob Nevins wrote:
>>> One last request for an updated package: can you ensure that users
>>> aren't going to run into freeciv-gtk3 unless they go looking for it?
>>> While it's more or less playable, it really isn't ready for prime time
>>> yet :/
>    [...]
>>> I'm not sure what the fix is; in increasing order of disruption:
>    [other proposals snipped]
>>>  - stop packaging freeciv-gtk3 at all
>> 
>> Too late for Jessie.
> 
> I'd urge you to reconsider this.
> 
> The bug report from a Jessie user that I mentions turned out to be this:
> <http://gna.org/bugs/?22833>
> Being unable to found cities is a pretty fatal bug.
> 
> Marko Lindqvist also reports:
> 17:59 < cazfi> I certainly hope that the outcome is that gtk2-client is
>                switched to be the default before Jessie freeze in a couple of
>                weeks.
> 17:59 < cazfi> Latest update of gtk+-3 libraries seem to have broken our
>                gtk3-client quite completely.
> 18:00 < cazfi> I've been forced to switch back to gtk2-client myself.
> 
> I don't know if this affects Jessie; that looks like it's getting
> gtk+3.0 3.14.3-1, which is fairly modern.


Currently we ship both GTK+ clients in the same package and people can
choose which one they want to use for playing. I personally believe that
the package description is now meaningful enough that all users can make
an informed decision.

As I said before splitting the clients into separate packages is now too
late for Jessie. In my opinion removing the GTK+ 3 client two weeks
before the freeze is also a rather disruptive change and I would have
expected more bug reports in the past months from people if the
situation was really that bad. This comes somewhat as a surprise for
people who played the game during the past months and years. Such
changes should be better made several months before the freeze.

I think for most of Debian's users it is already clear that we simply
provide multiple clients for their convenience although we know that
only the GTK+ 2 client is the most reliable and preferred client of the
project. We could have saved us a lot of work, if we had stopped
shipping all other clients except GTK+ 2 a long time ago.


> Dropping the gtk3 client is a loss to users, but better that that
> happens before it first hits a stable release. And it's not a loss in
> actual functionality; for the most part the Gtk2 and Gtk3 clients are
> feature-equivalent.
> 
> I don't know if you'd need to plead specially with the release managers
> for a change like this, but I'd have thought 'drop experimental binary
> that was packaged prematurely' would be an easy sell; it should be
> low-risk to the release (just remove the binary and dependencies). I'm
> happy to weigh in on the conversation as an upstream.
> 
> Otherwise I fear we're going to get a stream of bug reports for years
> that we're not going to be able to do anything with.

If you insist as upstream developers on removing the GTK+ 3 client I
have absolutely no problem to implement this change for
freeciv-client-gtk since you also take responsibility for it. My main
concern is that our common practice of providing multiple clients is at
stake here. Actually I don't see any reason to continue providing
multiple clients because you can argue the same way for all other
clients. They are not feature complete and probably buggy.


>> Interesting topic. I have always wondered why there isn't a separate
>> GTK3 binary package.
> 
> Looks like it was Clint Adams that added it to freeciv-client-gtk, when
> packaging 2.4.0 (i.e. long after last Debian stable):
> <http://anonscm.debian.org/cgit/pkg-games/freeciv.git/commit/?id=9e801b436f75cdf2e2ceb51c4ea877cce70d1f32>
> 
> I'd now argue that was premature (although we upstream would probably
> have been more optimistic at the time).
> 
>>>  - edit the .desktop file to say it's experimental
>> 
>> I'm not sure if this would really help to mitigate the problem. People
>> tend to ignore warnings. :)
> 
> Indeed. Thanks for adding the note to the package description in
> 2.4.3-3, but I now think that won't be sufficient.
> 
>> I would also suggest to add the experimental tag upstream.
> 
> It's a thought; currently it's in the 'maintained' list in 'configure'
> (but then so is Xaw). We were more optimistic when we did that.
> 
>> I think we should keep it this way for Jessie and split the GTK
>> clients into two separate packages for Jessie+1.
> 
> Indeed, I agree reintroducing it this way is a medium term solution, and
> that attempting it for Jessie would be a poor plan.
> 
>> But if you really think that the GTK3 client is unfinished and/or
>> broken, then it should be removed with the next major update in
>> Freeciv 2.5. Although my hope is that it will be improved in the
>> future and become a replacement for the GTK2 client.
> 
> Well, so do we, obviously. But getting it to release quality is proving
> to be frustratingly slow. Most improvements that it's getting are being
> backpored to 2.4 at the moment, but I suspect we're going to have to
> declare a fairly high minimum Gtk3 library version before we're done.
> 
>>> I can raise a Debian bug for this if you'd prefer.
>> 
>> You don't need to file a new bug report for this issue now but it makes
>> sense to keep this kind of e-mail conversation public in the future so
>> that other interested parties know why the crazy Debian people made that
>> kind of decision or not. ;)
> 
> I agree, but I wasn't sure where to discuss general packaging plans.
> Perhaps I should have been Ccing pkg-games-devel@ ?
> 
> If we agree that Gtk3 can be dropped I'll raise a bug with excerpts from
> this conversation. I wouldn't expect a huge outcry, but you never know.
> I can't see any reasonable argument that users would lose anything
> important.

I have opened a bug report now. All bug reports against Freeciv are
automatically forwarded to pkg-games-devel. Although if you want to
discuss anything about the game without wanting to file a bug report, I
suggest to use debian-devel-games in the future. I'm currently the only
active maintainer of Freeciv but the game is still team maintained.

>> What do you think about the xaw3d and QT client? Are there many people
>> who would prefer a separate xaw client for Freeciv or shall we drop it
>> with 2.5? I think a QT client would be a useful addition but is it ready?
> 
> Xaw is not getting any real maintenance and doesn't work reliably when I
> try it. I suspect you should drop it. I'm not saying that no-one will
> scream -- we occasionally get people upstream saying they'll maintain
> it, but no-one actually has for ages.

Ok, that's what I meant before. I would prefer to drop it for Jessie+1.
The package description is currently meaningful enough IMO.

> Qt is coming along quite well; in 2.5.0-beta2 it will have most
> functionality basically complete and have 'maintained' status, for what
> that means. I haven't played it much myself, and I suspect there are
> still rough edges, but I think it will be worth packaging when 2.5 hits
> Debian (in a separate package). It may turn out to have similar status
> to the Gtk3 client; I think it's too early to tell.
> (For avoidance of doubt, there will never be any point packaging 2.4's
> freeciv-qt, it does nothing.)

Now I'm not so sure anymore if we should package the Qt client at all
because the risk is apparently high that the same thing happens to it as
with the GTK+ 3 client.

Don't get me wrong. I have no problems to package several clients for
Freeciv but there should be some concept behind it. If it turns out that
all clients except the GTK+ 2 client are experimental and not playable,
it might be better to drop them all together. That would save time on
the maintenance side and would produce less confusion amongst our users.

On the other hand if Debian should continue to ship multiple clients of
Freeciv, we need a clear message from you how we should promote them, so
that we can avoid this kind of situation in the future, where we are
forced to make disruptive changes shortly before a freeze.

Regards,

Markus



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20141021/4fd3d441/attachment.sig>


More information about the Pkg-games-devel mailing list