[Tilesathome] Problem under windows again

[Ævar Arnfjörð Bjarmason]

On Fri, Aug 22, 2008 at 6:52 PM, Carsten Möller <cmindividual at gmx.de> wrote:
> I meant 90% of all possible users, not current tah client users.
> By the way, is here any Windows-User in this group, who has
> successfully uploaded tilesets, lately?

(Disclaimer: I haven't written a line of code for t at h)

Just because 90% of all computer users use windows that doesn't mean
that 90% of all potential users of t at h are Windows users, claiming
that is just a gross misuse of statistics. For one thing you can look
at the total numbers of Perl users on Windows to see that that's just
not true, despite the perl interpreter being quite successfully ported
to win32 Pers users on Unix-like systems still far outnumber win32
users.

Having said that the people in this thread are quite correct in
pointing out that if you want to get anywhere with t at h on win32 you're
either going to have to do it yourself or find someone who will. You
obviously seem to care about it so why not maintain the port? Porting
pure-Perl code to a new platform is generally quite easy and mostly
involves changing hardcoded stuff that has to do with filesystem
functions to use core modules that are portable and other such mundane
stuff.

And, to reply to your earlier suggestion that t at h changes be developed
in branches, tested and then merged into trunk when "they're ready"
that leads to problems of its own. I've been apart of a major free
software project (MediaWiki) that used to do that but abandoned it
because what you had as a result of that was people basically working
on neat features that were mostly untested in their own branches. And
when you wanted to make a release from those, or in the case of
MediaWiki deploy them on wikipedia.org you had this really painful
process sometimes going over many months where you found that most of
that was broken in one way or another so you had to fix all sorts of
bugs, some of which ended up on the live site and were much harder to
fix because they were part of a larger and untested codebase.

MediaWiki now does what t at h does and runs the live site from svn
trunk, which I really think is a much better solution overall because
although you do get occasional breakage you don't get into this huge
deployment process where everything breaks apart once you try to merge
it all back into production. It's really hell for the devs working on
it too because they end up spending a majority of their time working
in the dark as opposed to making incremental changes on something
that's known to work, and either those changes screw everything up
immediately in which case they're fixed quickly, or in the more likely
case they work in production and more neat features can be developed
in the certainty that they're not being built on sand.