Don't you feel that the
buildability/runability is somewhat alleviated by the existance of
jhbuild? I do help many people in IRC to get this environment set
up and get them up and running for the whole gnome project.

And on the other hand, we got many drive-bys for our Vala games.
Even more complex patches.

Am 16.04.2014 14:02, schrieb John Stowers:

Hi,

The thing is, I don't think these positions are consistent.

If I was trying to maximize drive by contributions I would
consider

* total popularity of language X

* popularity of language X inside GNOME

If I was optimizing for maintainability then I would
choose

* all languages to be the same (when g-g was in the same
git module)

* the language the maintainers know (now they are separate)

If I was optimizing for games *to have a maintainer* I
would

* choose games that have a maintainer

In my experience maximizing drive-by contributions is done
through engagement with interested parties, publicity, and
making the code easy to run and test.

I get patches because gnome-tweak-tool can be git cloned
and run against any version of GNOME without being
compiled/installed/run in jhbuild/etc.

To that end I see here

* decisions being made that show disinterest toward
willing maintainers (of new and existing games)

* the insistence on using a language that is not easy to
run from a git checkout (how is my vala compiler version this
week). E.g. _javascript_/python

yeah, we prefer Vala. The main problem is, that we
always fear that the original developer won't be the
maintainer forever. This is now the case for all our
games. The barrier for entry is very high for C. Any
programmer's experience with Java or C# (one or both
should be taught to a reasonable degree at every
University) is a good starting point. The amount of C I
finished my bachelor's degree with was next to nothing.
Look at this bug: https://bugzilla.gnome.org/show_bug.cgi?id=613077
This was open for four years. My resolution ( https://git.gnome.org/browse/gnome-robots/commit/?id=ab5caae53dc4dfa71f242b7e83a40e650e825baf)
changed the position of one line. Usually, one would
hope, that such a bug would have been fixed at least by
a drive-by-patch (during the 4-year-period).

We do believe that everyone who proposes a game (and has
it written) is proficient in that language. But no one
can guarantee that the original developer is around next
year when changes have to be made (like the general
inclusion of header bars for toolbars during the last
months). With that in mind it is easier for the
maintainers to have a single language the codebase is in
and a core set of used libraries (the gtk-stack) instead
of language and library fragmentation (like the original
poster with "hamster" as a drawing library). I maintain
5 of the 15 games and it is a lot of work as it is.

Again, nobody is denying that "your" C is good. But
"our" C is bad and "we" fear that "we" will be the ones
who end up supporting the application once "you" are
gone.

I hope you understand our reasoning behind this :)

Mario
Am 16.04.2014 09:53, schrieb Vest V.:

Hello Mario,

> We're currently looking to port all games
to Vala to have the benefits of
> a modern language and still use all the
up-to-date C bindings of the
> Gnome/Gtk-stack. Still, this type of
game, in principle, could fit into
> our portfolio and I like it very much.

A long time ago, when I asked about my game,
somebody from the list told me that there is a
chance to review the game if it is written in
Vala/C + Clutter + GTK (my old game was written
in C++ / GTKmm + Cairomm). Now, I see that the
trend has been moved to pure Vala. Am I correct,
that Vala is more preferable than C (even if
objects based on glib classes are used)?