Hi David and all!
I think it is a very important moment in our project. You are true
when say that we shall get stable our projects before we begin new
feautures. Sadly, many of us don't have all the time we want to invest
in tux4kids. If we participate this year, we should be very strict in
the aplications we will accept. And if we decide not to participate
this year we should put a list of goals to do.
2011/2/21 David Bruce <davidstuartbruce@...>:
> The application period for projects interested in GSoC opens Feb 28.
> Are any of the previous mentors interested in being GSoC admin for
> Tux4Kids this year? I've done it the last two years, and would be
> more than happy if someone else wants to take over. I love working on
> this stuff, but it is an increasing source of unhappiness for those
> around me, who view all this as me "playing on the computer again".
> So, I really don't want to be GSoC admin anymore.
> Also, speaking to the Tux Math and Tux Typing side, we have a ton of
> unfinished business up in the air. I'm not sure it even makes sense
> to participate in GSoC this year. It seems we start all these
> ambitious projects which get partially done, but never quite come to
> Tux History?
> Tux Typing has basically ground to a halt because we were waiting to
> get the t4k_common library shaped up (actually, that might be a GSoC
> project that would make sense - "port" tuxtype to use t4k_common).
> We haven't released a build of TuxMath for the Mac in almost 2 years.
> We haven't released a build of TuxType for Mac in over 3 years!
> The current version of tuxmath that uses t4k_common isn't packaged for
> any distro, AFAIK.
> We added a ton of cool features to tuxmath during Google Code-In
> (which, I may add, was massively time-consuming and got my family
> really mad at me), but most of them left various loose ends which need
> to be finished before a public release can be made. We haven't even
> gotten that out the door, and folks are clamoring to do more big
> changes to the program ("I'm going to rewrite mathcards from scratch".
> "I'm going to put in a new event architecture that will completely
> break the existing LAN game". "Let's remove all the network code and
> rewrite everything from scratch." "Let's move the entire program to
> C++"). I think these are the last things we should be considering at
> this point.
> Sorry about the rant, but I'm getting more and more convinced that the
> project is suffering from GSoC-induced bloat. If we are going to take
> part again, we should tightly restrict the number of participants, and
> make certain that the projects don't lead to even more unfinished
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> Tuxmath-devel mailing list