Re: [gentoo-soc] Proposal draft, feedback appreciated

[Andrey Falko]

On 3/25/09, Nils <nils.schlupp@×××××.com> wrote:
> Hey,
>  Here is my draft proposal, I would appreciate it if anyone could look
>  these over and then let me know if anything needs clarification or
>  there is anything else i should add.
>
>  Thanks,
>  Nils Schlupp
>
>

Find some of my feedback below Hopefully it is rigerous enough
feedback that'll help you create a much stronger proposal. I tried
asking you questions that I think you ought to answer for sake of
clarity and direction.

I didn't give feedback on your milestones because in general you
should revisit them after you revise the deliverables section.

>
>  Proposal for an SCM snapshot management infrastructure:
>
>  1.Objective – The objective of this project is to make it easier for
>  maintainers to generate snapshots of packages that are pulled from
>  SCM, since some projects do not produce source downloads outside of
>  their SCM system.

End the sentance at "from SCM". Then make the next sentance something like
"There are projects that produce..., for example x, y, and z"

What is your estimate of how many projects that only use SCM?

> This will have multiple benefits. For once, we
>  remove reliance on the upstream SCM server, which might not be able to
>  cope with the load.

"For once" -> First

Load of Gentoo Users?

> Also, we can insure the code the user receives,
>  even when upstream changes their tags.

"insure" -> ensure

This sentance should be rewritten to express your point better:
perhaps. "Second, we ensure that the code..."

> The only current solution is
>  for maintainers to manually generate snapshots and distribute these
>  through the Gentoo infrastructure.
>  2.Abstract – This project will produce a daemon which will
>  periodically check the upstream SCM servers for changes and then
>  notify the maintainer of the package of this change. It will also
>  locate all ebuilds using the new eclass and generate snapshots for
>  them, maybe have maintainers check these for integrity, upload them to
>  the infrastructure, and then modify the ebuild to include the url of
>  the snapshot.

What new eclass? Why is an eclass needed? Please describe it in more
detail, perhaps provide examples of how it would be used.

Are the reasons why the daemon can't automatically upload them to
infrastructure?

>  3.Deliverables – This project will produce one daemon which will be
>  taking care of these tasks, as well as an eclass to be used in
>  conjunction with it.

You need to expand in this section much more. Where will this daemon
run? What does the eclass do specifically?

Will you update existing ebuilds to use your new eclass? If not, why not?

>  4.Milestones: (Not in order)
>   1.Be able to search the entire tree efficiently for ebuilds
>  requiring snapshot generation.
>   2.Be capable to generate snapshots given a variety of SCM uri's and
>  tag/branch combinations.
>   3.Be able to scan repositories for changes in the source for this
>  particular package.
>   4.Be able to notify maintainers.
>   5.Be able to upload snapshots to the required location to have it
>  propagate through the infrastructure.
>   6.Be able to modify the ebuild to add the new snapshot url and
>  update the manifest.
>   7.Generate an eclass to work in conjunction with the daemon.
>  5.Timeline:
>   1.May 28: Final design specifications. This will be produced after
>  discussions with the infra team, especially on how to best notify the
>  daemon of new ebuilds, as well as where it will be located, and how it
>  will interact with the tree.
>   2.June 18: Have completed at least milestone 1 and moved forward in
>  milestones 2 and 3.
>   3.July 9: Have completed Milestones 1-3, most likely 4, as well as
>  develop a plan for milestones 5 and 7.
>   4.July 30: Have completed milestones 1-7
>   5.August 6: Hopefully all bug free :)
>   6.August 10: All done, some cleanup and minor optimisation.
>   7.August 17: Release version 1.0.
>  6.Development Experience:
>   1.Programmer for high school robotics team (Botball competition) and
>  now college robotics club (Mostly c and derivatives).
>   2.Developer for the Auto-Ndiswrapper project
>   3.Scripting Linux for 1-2 years (Bash, Python).
>   4.2 years of programming education (in Java).
>  7.Biography – I was born on January 8th, 1990 in Hamburg, Germany. I
>  moved between Germany and the US numerous times, and have also lived
>  in Switzerland for a while. Currently I am located in Norman, Oklahoma
>  where I am attending the University of Oklahoma. I am majoring in
>  Engineering Physics, while pursuing a second major/minor in CS. My
>  interest has always been Robotics, and in the past 2-3 years it has
>  shifted from the mechanical side over to the programming aspect. I am
>  especially interested in artificial intelligence in multi agent
>  systems, where multiple robots are programmed to work together, share
>  information, and make independent decisions. I have been using Linux
>  for around 2 years by now, and been using Gentoo for little over one
>  year by now. This has also been the point at which I started to become
>  interested in the inner workings of Linux, which has in part lead me
>  to Gentoo and now to the Gsoc.
>
>