Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27

[Jerome Leclanche]

On Sat, Feb 11, 2012 at 2:50 PM, Maarten Lankhorst
<m.b.lankhorst at gmail.com>wrote:

> 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/**SummerOfCode<http://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20120211/4016cf9a/attachment.html>