[gentoo-soc] Proposal draft, feedback appreciated

[Nils]

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



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. 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. Also, we can insure the code the user receives,
even when upstream changes their tags. 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.
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.
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.