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
John
On Wed, Apr 16, 2014 at 12:53 PM, Mario Wenzel <maweki gmail com> wrote:
Hi Vest,
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.:
Kind regards,Hello Mario,
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)?
> 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.
Vest
_______________________________________________ games-list mailing list games-list gnome org https://mail.gnome.org/mailman/listinfo/games-list
_______________________________________________
games-list mailing list
games-list gnome org
https://mail.gnome.org/mailman/listinfo/games-list