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

[Marcus Meissner]

On Sat, Feb 11, 2012 at 03:56:43PM +0000, Jerome Leclanche wrote:
> 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.

A GSoC really needs to be measurable somehow... Partially as psychological
aspect for both student and project (to see that somehting was achieved),
but also for fairness and proof if anyone would ever ask.

Helping developing parts is not well measurable :/

Ciao, Marcus