Re: Google Summer of Code 2007

[Thomas Schwinge]

Hello!

Thanks for the feedback!


On Mon, Mar 12, 2007 at 04:09:25PM +0200, Constantine Kousoulos wrote:
> IMHO, o GSoC project should be something doable that can be 
> completed within the given time. Too broad tasks should be avoided.

Correct.  However, it's often difficult to estimate whether a task fits
into that categorization or not.

> Libchannel is a prerequisitive for many proposed projects. I think 
> that any project that depends on it, should not be proposed. IMHO, 
> each project should be independed of the others for maximum 
> efficiency.

Also correct.  However, if two people that are know to work together want
to work parallel to each other, say one on libchannel and the other on
pfinet, then that can only help as both of them then can help each other
and base their things on what the other one actually needs.  But of
course that'll only work for sufficiently skilled people.

> AFS? Ext2fs is not working at 100%. Ext3fs support is virtually 
> null. Ognyan Kulev worked on ext3fs, but all his work is 
> documented in bulgarian :(. Why bother with AFS?

Correct.  However, the Google Summer of Code is about writing code.
Tracing down bugs in ext2fs plus all the libraries -- finally even down
to Mach! -- is certainly needed, but can't be done as a GSoC project.
Likewise, someone having a look at Ognyan's ext3fs code and all the
journaling libraries he wrote / ported / extended would be a very welcome
thing to do, but is again not possible as a GSoC project.

> cthreads-->pthreads: From time to time the same question arises. 
> What is the status of pthread support? Does this task involve bug 
> fixing or code writing? From my limited experience i tend to think 
> it's more of the former, but then again i really don't know.

There are already patches for a number of libraries and translators to
convert them to pthreads, but it's not finished at all.  I don't think
that too much code-writing should be needed and it'll be more like
integrating everything and bug fixing and so on and given that, the
question again is whether it's then really suitable as a GSoC project.

> Glue code update: Finally something i have personal experience of. 
> I think it's too complex to be on GSoC. For more details, see one 
> of my old posts here 
> http://lists.gnu.org/archive/html/bug-hurd/2006-11/msg00076.html. 
> Linux has all the documention we need to write new glue code. 
> However, Mach has almost no documentation on how to write device 
> driver code. I believe this is a long term project that can only 
> be accomplished under the close guidance of an experienced mentor.

That may very well be true, yes.  However, if someone is already
experience in Linux or *BSD kernel code, it may be easier for her than it
was for you (not an expert in such code, if I remember correctly) when
you gave it a try.


Also note, that we don't have to accept people when they have applied for
a project.  If we -- upon having evaluated their application -- talk to
them and get to the understanding that they're not the right ones to do
the job, then there's no problem with instead prefering other people
working on other projects, within the GNU project's list of items.
(Remember that a fixed number of GSoC slots will be assigned to each
mentoring organization.)


If someone has further comments, then please post them quickly: I'll very
soon post the list of project I'm going to come up with to the GNU GSoC
administrators to have it oncluded in the GNU list of project; students
can begin applying to project tomorrow.


Regards,
 Thomas

signature.asc
Description: Digital signature