Age | Commit message (Collapse) | Author |
|
|
|
A modular implementation is not realistic in the GSoC timeframe; and
starting with a monolithic one probably makes sense from an engineering
standpoint anyways. Also, it's probably better than what we have now...
|
|
|
|
The stuff Andrei worked on last year isn't quite ready yet, but leave it
for now...
|
|
|
|
Mention Zheng Da's socket overriding patch as an example of approach
(1), intead of mentioning it in the "status" section.
|
|
|
|
|
|
|
|
|
|
While the procfs produced in last year's GSoC is still very buggy, this
probably doesn't justify another GSoC project.
|
|
While the suggestion is certainly good as an exercise, it is probably
not suitable for producing an actual patch quickly. Warn about this, and
explicitely mention that finding a different task might be necessary.
|
|
Sergiu Ivanov is working on this.
|
|
Zheng Da is currently working on rootless subhurds etc.
|
|
Explicitely mention that the previous work can serve as a reference only
-- most likely we can't use it directly because of missing copyright
assignment. Probably it also uses a suboptimal technical approach.
(Haven't checked.)
|
|
|
|
|
|
|
|
|
|
This gives us better control -- in particular over the ordering.
It will also allow easily disabling ideas without removing them
alltogether, which I consider useful.
|
|
|
|
This way it can be pasted into the application form directly.
|
|
|
|
Make it clear that we explicitely require the students to contact us,
and to submit a patch as part of the application process.
Most of this information is redundant with the introduction section of
the student application form. This is not a problem: If they read it
twice, there is a better chance that they will take it seriously...
|
|
|
|
|
|
|
|
The main purpose is to get a clear statement about whether the student
intends to stick around after the end of GSoC...
|
|
|
|
|
|
application form
While these questions are related in establishing how much time the
student will work on the project, they need to be handled (and
explained) distinctly.
|
|
|
|
|
|
Dropped bit about mailing list experience in general. It doesn't really
mattter for our selection process.
Also, make it explicit that this in not really a question, but rather a
hint to subscribe ASAP.
|
|
|
|
|
|
The purpose of these question was to encourage students to get some
experience with using and developing Hurd during the application
process. This indirect hint didn't really work anyways; and it's not
necessary anymore, as we now explicitely require submitting a patch.
|
|
application form
The students should have enough chance to get familiar with the process
while creating/submitting a patch, required as part of the application
process.
|
|
|
|
student application form
|
|
|
|
|
|
|
|
Aside from rewording in general, we now explicitely demand that students
contact us during the application period -- instead of just suggesting that
they will really need to do so in order to properly answer the questions, and
hoping that they take the hint... It is important that they contact us, and
there is really no reason not to demand it explicitely.
Also, introducing explicit patch requirement. (Instead of just asking for some
"exercises" through the feedback form after they submit their applications...)
Generally, we try to be much more clear about our expectations up front. This
should make our work much easier when giving feedback for the applications.
Also it should result in better applications -- and more happy students...
|
|
The FAQ for this year no longer explicitely mentions a limit -- although it
still talks about external links... Let's assume there is no limit anymore.
|
|
|
|
|
|
|
|
Also adapted question about no previous participation...
|
|
This will probably make the Google folks happy, as this is officially the main
purpose of the GSoC program...
More importantly, past experience shows that even very skilled students are
seldom able to leave a project in such a state that it is really useful for us
without any followup work -- treating GSoC as a way to get code written by
means of external sponsoring doesn't really work out. Finding long-term
contributors is *much* more useful in the end.
|