On Sat, Feb 11, 2012 at 2:50 PM, Maarten Lankhorst m.b.lankhorst@gmail.comwrote:
Hey Jeremy,
Op 10-02-12 20:23, Jeremy White schreef:
Hi Folks,
It's that time of year again - summer of code is going to start up soon.
Maarten, you've been coordinating things for us for a while now - are you still game? Would you like help? Anyone else willing to volunteer to help admin the process?
I'll apply wine again this year, but I want to ask everyone to help
update our summer of code project wiki page.
http://wiki.winehq.org/**SummerOfCodehttp://wiki.winehq.org/SummerOfCode
I feel like we're not getting enough accessible projects that also have the correct length. I'm looking for something that's non-trivial but can still be done incrementally, having huge delta's to winehq has proven to not lead to meaningful contributions, and some of the projects on that list are too small, too complicated or might not be integrated into wine because it would be above a student's level get it done right.
I have my doubts about these for example:
- Message mode pipes - if AJ doesn't know how to do it, how can a student
do it right?
- Sandboxing, what's to prevent an app from simply doing syscalls in
assembly, a real sandbox is not going to work
- Richedit windowless mode - There's no way this can be a student project
until someone does the thiscall that works both ways, this has been the biggest stumbling block to implementing it.
- TestSuite - All previous attempts have failed, I believe that compiling
testsuites for other projects would be a good project instead, fixing all problems that show up and don't show up on windows. Improving winetestbot to something more standardized and maintained would be nice too, but hardly a summer of code project, since it's too short.
But that's just my opinion, feel free to add your own projects to that list. :-)
~Maarten
The problem with GSOC projects, in my opinion, is that too many people see them as "projects"; the kind that needs to be finished by a deadline and have visible changes, new gui or this sort of thing.
While there are interesting bits that could be done that way, having looked at a lot of bugs and their lifetime it feels to me there are areas of wine that could just use generic improvements, which are the kind that help wine the most: gradually implemented, tends to have a visible impact on bugs, many different areas to pick from, etc. The uniscribe/bidi improvements over the past few releases are a good example of a project that could have been picked up by someone familiar with/willing to familiarise themselves with the area.
J. Leclanche