Comments please: Ports 2.0 SoC application to Google

[Aryeh M. Friedman]

Tobias Roth wrote:
> Aryeh M. Friedman wrote:
>
>   
>>   Kip Macy <kip.macy at gmail.com> has agreed to be the mentor for the
>> project if accepted as a SoC project provided that no other suitable
>> mentor can be found.   For detailed development schedule see the
>> "Detailed Description" portion of the this application.   I have used
>> FreeBSD since 1995 and before returning to school worked as a research
>> scientist and director of R&D for a very early pioneer of streaming
>> media which was a 100% FreeBSD shop and required substantial
>> modifications to the network stack and file subsytems of the kernel
>> (most of which have been since incorporated into the mainstream TCP/IP
>> stack/kernel and/or made unnecessary by them).   See resume for more
>> detail.
>>     
>
> So, who will be the mentor? You or Kip?
>   

Kip is the mentor but since before returning to school, as I said, I 
have had executive level responsibilities so am able to work with 
minimal supervision.
>
>   
>>   Key Milestones and deadlines:
>>
>>       Milestone                Deadline
>>       ------------------------------------------------
>>       Complete the build skeleton        Week 1
>>     

Demostrate ability to compile and test all components using placeholder 
code.
>>       Complete the graph library        Week 3
>>     

Demonstrate ability to construct dependency DAG and do a DFS, BFS and 
Topo Search on it.
>>       Dependency scanning            Week 5
>>     

Create an accurate build order list for some subset of ports with the 
minimum some non-root node sharing common dependencies.

>>       Demonstration of dry run over xorg and    Week 6
>>        items from feature 6
>>     

Produce a completely accurate build order and echo the appropriate 
commands that would build each port
>>       Demonstration of building an         Week 7
>>       non-cyclical ports graph
>>     

Show the systems ability to install and update some port that has no 
common ancestors
>>       Alpha test of xorg build        Week 9
>>     

Xorg builds without problem on my machine

>>       Beta test of xorg build            Week 11
>>     

Xorg builds without problem on at least 3 other configurations beyond my 
machine.

>>       Complete API and theoretical         Week 12
>>       documentation
>>     
>
>   

Document all public methods and give enough theortical background so 
that a module developer will not inadvertently break the system.


See in line comments.  General comments from my R&D experience I have 
learned to leave milestones as vague as possible because by the very 
nature of R&D you generally don't know the outcome before you try to 
create it.
> These seem very vague on first glance. Milestones have to have a
> measurable level of completeness, i.e. if you as an implementor or
> contractor claim the milestone is done, I as a project manager have to
> be able to verify it really is. Things like "Dependency scanning" don't
> qualify.
>
> More examples:
>
> Instead of "Complete the graph library", list the necessary features of
> that library. Or, instead of "Alpha test of xorg build", describe tests
> that have to pass, and make sure what the difference between "Alpha and
> Beta" is in that case.
>
>
> I admit I haven't read through all of the Wiki entry, so maybe that
> information is there to be found. But don't expect a person at Google
> with hundreds of applications in front of him or her to go and collect
> data from various websites. This stuff has to be in the proposal, and it
> has to be detailed.
>
> As it is now, I would never accept this task as a contractor, because
> it's not clear what exactly the outcome has to look like in order for me
> to get my money. I expect it's the same for SoC students and people at
> Google approving applications.
>
> Also, this doesn't look like it's even remotely possible to finish this
> in two months, but that's just an uneducated guess from my side.
>
> Regards,
> Tobias
>
>