Tobias Roth wrote:
Aryeh M. Friedman wrote:
Kip Macy <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
