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

[Nils]

Thanks for the feedback.
For now, i have moved the proposal over to google docs. If someone
could take one last final glance at it then that would be great.
The document is available at http://docs.google.com/Doc?id=dg3k7d6g_47dm77d7hk

Thanks a lot,
Nils Schlupp

Here is also a local copy just in case:

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. Some projects do not produce source downloads outside of their
SCM system. In my current portage tree i have located around 200
ebuild which rely on some sort of SCM. Many of these are live ebuilds,
but some are simply versioned or certain branches. Moving snapshots of
these packages to the Gentoo infrastructure will have multiple
benefits. First, we can ensure the integrity of the code the user
receives, even when upstream changes their tags or otherwise modifies
the code the user is trying to access. The only current solution is
for maintainers to manually generate snapshots and distribute these
through the Gentoo infrastructure. Secondly, we can guarantee
availability even is the upstream server should have issues.
   2.  Abstract – This project will produce a daemon which will locate
all ebuilds using a new scm-snapshot eclass and generate snapshots for
them, possibly have maintainers check these for integrity, upload them
to the infrastructure, and then modify the ebuild to include the url
of the snapshot. It will also periodically scan The repositories to
locate any changes and then update the snapshots, as well as notify
the maintainers. The eclass will be provided in order to allow
maintainers to opt-in on this, or to just remain with the current
system. It will also handle the cases there the snapshot cannot be
located or fails. In these cases it passes the ebuild on to the
original scm class to handle.
   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. The daemon will most likely be run as a cronjob
on the infrastructure itself, but details would need to be worked out
with the infrastructure team. It will save its current state as a
pickled file in order to be able to quickly resume work. The eclass
will provide the above described functionality.
   4. Changes to current architecture - This will produce a minimal
need to adjust. I will inform current maintainers of the possibility
to use this system, and help them migrate to it. Migration should not
require much more then adding the new eclass to the inherit line and
maybe a quick call to a function or two in the prepare statement.
   5. 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.
   6. 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.
   7. 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).
   8. 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.