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
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
