Date: Wed, 25 Feb 2009 11:37:51 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Siddharth Prakash Singh <spsneo@gmail.com> Cc: Jordan Gordeev <jgordeev@dir.bg>, freebsd-hackers@freebsd.org Subject: Re: Google SoC 2009 Idea Message-ID: <20090225113751.62205vkw7ui1ax6o@webmail.leidinger.net> In-Reply-To: <e8e9f3930902241743n3f650698r389137caa048daf2@mail.gmail.com> References: <e8e9f3930902240943o2e2f4b1bh34916b775692a26f@mail.gmail.com> <1aa142960902241100u671d5f90u769ad98e08fabb43@mail.gmail.com> <e8e9f3930902241107j2e53c9fai9942ab14167831f@mail.gmail.com> <49A447C5.2020903@freebsd.org> <49A457CA.20704@dir.bg> <e8e9f3930902241743n3f650698r389137caa048daf2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Siddharth Prakash Singh <spsneo@gmail.com> (from Wed, 25 Feb 2009 07:13:05 +0530): > Yeah I sent the same proposal to all the *BSD mailing list, because I > am interested in doing this project . What's wrong in proposing the > same project in all the *BSD organizations? As one of the FreeBSD mentors for some GSoC's in the past: nothing is wrong with proposing the same project to several *BSD projects, that's not unusual and happened in the past several times. What's not so nice is to propose something without looking at the existing features in this area. It's not just saying "I want to do something like this". When you submit your proposal to Google, we expect that you looked at the corresponding code and at least know most of the features. You are not supposed to know each line of code or to understand each line of code, but you should know what is there, and what you need to do until your goal is achieved. For example in one of the past GSoC's proposals told that in the XYZ subsystem A, B and C "is missing". They contained a timeframe which explained how much time the student expects until each feature is implemented. For some stuff (API compatibility) even a list of missing functions was presented. You have to understand that in the past we got between 10 and 20 students during the GSoC. For those 10-20 slots there where more than 100 proposals (more in the range of 200-300). Those proposals where filtered by Google, so we've seen only those, which where not immediately rejected by Google because of lack of content. Those proposals have to be rated by the FreeBSD committers which are willing to mentor students, and they do this based upon several checkpoints. We look at the proposal and look if it is actually possible to do what is proposed. Not only in general, also during the timeframe of the GSoC and by a student. It is also not important that all features are completed, so if we think that the student is able to e.g. handle 80% of what he proposes and if we also think that this is ok for us, then we give some points to the proposal. This means that the student has to show that he understands what he is talking about and that he has also some insight into what he has to do and some expectation how long it takes. In the end the proposals with the most points (and someone willing to mentor this project) are taken. So the better the proposal is, more likely it will be that the proposal is accepted. When you look at the FreeBSD ideas page, you see the bare minimum what information needs to be in the proposal (nobody needs to write the required skills in a proposal). When we see a proposal which is just a copy of what we have on the ideas page, it will not get that much points, as it doesn't show if the students really understands what he is proposing. Bye, Alexander. > On Wed, Feb 25, 2009 at 1:55 AM, Jordan Gordeev <jgordeev@dir.bg> wrote: >> Sam Leffler wrote: >>> >>> Siddharth Prakash Singh wrote: >>>> >>>> On Wed, Feb 25, 2009 at 12:30 AM, Ray Mihm <ray.mihm@gmail.com> wrote: >>>> >>>>>> >>>>>> Title: Multicore Aware Process Scheduler. >>>>>> I have not gone through the process scheduler code of Free BSD. >>>>>> Hence, I am not yet aware about the current support for Multicore >>>>>> Architectures. >>>>>> >>>>> >>>>> Talk to jeff@freebsd.org, the author of ULE. >>>>> >>>> >>>> What are your opinions on this project? What is the scope of this >>>> project? >>>> >>>>>> >>>>>> Linux Kernel 2.6.* currently supports SMP, SMT, NUMA architectures. >>>>>> >>>> >>>> Does the current scheduler has support for "CPU affinity/binding", >>>> mechanism for distinguishing varying capability of CPUs. >>>> >>>>> >>>>> These may be there already in ULE, although I'm not sure about NUMA. >>>>> >>>>> Ray >>>>> >>>>> >>>> >>>> Waiting for your response, >>>> >>>> >>> >>> I note you sent this same note to the netbsd mailing lists. You might >>> want to do some more investigation before you propose a project. >>> >>> Sam >>> >> It was also sent to the DragonFly mailing lists. :-) >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > > > -- > Siddharth Prakash Singh > http://www.spsneo.com > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > -- There is a certain impertinence in allowing oneself to be burned for an opinion. -- Anatole France http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090225113751.62205vkw7ui1ax6o>