unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Paul Raccuglia <praccugl@haverford.edu>
To: guile-devel@gnu.org
Subject: Re: Hi! Interested in GSoC. Feedback on these ideas?
Date: Fri, 8 Apr 2011 00:36:16 -0400	[thread overview]
Message-ID: <BANLkTikNNP1AGbOeuwMU4oAwK7eB5o3wJQ@mail.gmail.com> (raw)
In-Reply-To: <BANLkTimxCQceZV=2mPpcuqwdTnwMi1tvaA@mail.gmail.com>

Here's the raw text of my application. The deadline is in about 11
hours, but I'll try to take into account any feedback.
Thanks,
-Paul


Your name
   Paul Raccuglia
Your email address
   praccugl@haverford.edu
   praccu@gmail.com
The name of the project
Guile – Implementing a user-friendly package manager and repository
Summary
Guile lacks a centralized, easy-to-use system for installing packages.
In the vein of apt-get and CPAN, this project will simplify the
process of distributing and acquiring packages in Guile. There exist a
number of code bases that could be very useful for this implementation
(notably including http://nixos.org/nix/ and
http://home.gna.org/dorodango/ ). I will implement an online
repository and a local client to acquire, install, update and manage
packages and their dependencies.
Benefits
   This project will benefit users of Guile by making it easy for them
to incorporate packages into their software. This is a vital feature
of a number of widely adopted projects, notably PERL, PHP and Python
(http://en.wikipedia.org/wiki/List_of_software_package_management_systems#Application-level_package_managers).
A robust, easy-to-use package manager and repository would help Guile
achieve wider adoption: ideally, easy-to-install packages would
attract a wider audience, and a good distribution mechanism will help
developer’s packages gain wider adoption.
Deliverables
There will be some alterations to existing Guile code, but most of
this project’s code will be new features.  The project will rely on a
set of fundamental sections of code: client code that acquires and
verifies the package and any dependencies (or updates to installed
packages); code that manages the packages locally (installing and
uninstalling, storing, unpacking); and code that merges upgrades into
installed packages intelligently. The client code will likely draw
from other projects.
In addition to the fundamental parts of the project, a web based
repository browser will be needed. The project will establish a set of
conventions for how this repository functions, and provide an
implementation of a repository browser.
Once the core functionality of this project is in place, it should be
structured so that adding features is relatively painless. My goal is
for the code to be easy to improve and maintain in a way that does not
depend on my involvement.
Additionally, this project will need to establish an easy-to-use but
robust set of conventions for packages, which will require clear
documentation. Packages should be acquirable from an official
repository, but unofficial sources should be allowable if the user so
chooses.
Plan
Proposal Timeline:
Before April 25:
-Begin to work with the guile-devel mailing-list and irc to establish
the project's design and conventions
-Do self coding with Guile to explore it more fully
-Discuss the project with friends and professors in addition to the
feedback I get from the guile community

April 25 - May 23: (before coding begins)
-Work to finalize the working design and conventions of the project
with my mentor, based on my conversations with the Guile community
-Continuing to work with the mailing list and irc throughout this period
-Review other projects that have tackled similar problems, make
decisions with the help of my mentor and the Guile community on what
to incorporate into the project
-Revise this plan as needed based on feedback, have a finalized
timeline prepared by May 23



May 24 - June 7: (Step 1: basic functionality)
-Write a client interface to Dorodango that handles acquiring packages
-Work on the basic manager to install / uninstall acquired packages
-Finalize preliminary design documents related to the structure of a repository
-Send a progress report / summary to the guile-devel mailing list once
this stage is finalized
-Acquire feedback from the community

June 8 - 22: (Step 2: distribution)
-Begin work on implementation of a repository
	*Implement a website that handles a browsable list of available
packages and provides details, dependencies, links, etc.
	*Write rudimentary administrator interface to add/edit packages
	*Handle communication of the client with the repository to identify
the appropriate package's location
-Continue work on client to interface with the repository to find packages
-Send a progress report / summary to the guile-devel mailing list once
this stage is finalized
-Acquire feedback from the community

June 23 - July 3: (Step 3: flesh out functionality)
-Flesh out the functionality of the client and the package manager to
include dependencies, handle updating, and sketch other essential
features. Have a list of essential features to be implemented after
the midterm evaluation
-Handle issues that have cropped up in the interim
-Code should be functional by the end of this period


July 4 - July 14: (Step 4: Clean-up for review)
-Clean up code, write documentation, fix any outstanding issues, and
complete evaluation
-Send a progress report to the guile-devel mailing list

July 15 - 17:
-Take a break, compile a list of issues, and write a revised plan for
the rest of the summer

July 18 - August 1: (Step 5: Finish functionality)
-Work on the client and manager, have all essential features working
-Work on the web client for the repository

August 2 - 8: (Step 6: Make sure it is accessible to other developers)
-Modify the client and manager code to facilitate adding nonessential
features easily

Aug 9 - 16: (Step 7: Finish up)
-Resolve outstanding flaws

August 16 - 22: (Step 8: Clean up)
-Test things, write documentation, clean up the code

September onwards:
-Continue to help maintain and support the results of the project


Communication
Communication depends on the time zone of my mentor. Email, IRC, and
phone conversations would be the main channels of communication.
Additionally, I will use git to upload my progress to a personal
(publicly-viewable) repository preferably on a daily basis and at
minimum a weekly basis. I will upload progress to github.com or
gitorious.org to facilitate inline conversations about the code.
I would like to note that I know Noah Lavine, a contributor to Guile.
If I ended up working with him in some fashion, I would be able to
communicate easily with him because he is in the same time zone, and I
am comfortable working with him.
Qualification
I am a CS/Math student at Haverford College, in Pennsylvania. I have
been coding on my own for about 10 years now. My older brother is an
experienced developer who gave me a lot of guidance as I was learning
to code.
This project appeals to me because it is a vital feature that Guile
lacks, a feature which will be important in Guile’s wider adoption. I
think Guile is very exciting, and hope that easing the barrier to
installing packages will help it grow.
This project also appealed to me compared to other projects I looked
at because it is made up of a set of relatively distinct, quantifiable
parts, which gives me confidence that it was a problem I could tackle.
I am suited to this in part because I have a pretty good understanding
of the general issues at hand, am a quick learner, because I am
comfortable working in C or Scheme, and because I have been coding and
learning and reading for long enough (approximately 10 years) in
enough languages (Python, PHP, C, C#, plus some work with Scheme and
Perl) to be acquainted with principals and processes of software
design. Plus, my older brother is an experienced developer who
continues to give me a lot of guidance in both general best practices
and giving me specific feedback on my code.
I already have a lot of the fundamental programming skills. The most
important things for me to improve will be to thoroughly familiarize
myself with the problem (over the course of the summer) and to develop
a strong relationship with the Guile community.
Once the project is “finished”, I hope to be able to steward and help
others to expand it. Ideally, the project will be easy to help
maintain and expand, so that I can focus my efforts on a different
issue (I am interested in working on a JIT compiler for Guile).
I have not worked on any serious Free Software projects before, only
used them; I am excited to start giving back to a project.



      parent reply	other threads:[~2011-04-08  4:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-07  0:40 Hi! Interested in GSoC. Feedback on these ideas? Paul Raccuglia
2011-04-07  3:36 ` nalaginrut
2011-04-07  8:31 ` Mark H Weaver
2011-04-07 13:10   ` Noah Lavine
2011-04-07 14:12     ` nalaginrut
2011-04-07 14:25     ` Problem with GCC as a Scheme compiler: tail calls Mark H Weaver
2011-04-07 14:37       ` Noah Lavine
2011-04-11 22:31         ` Andy Wingo
2011-04-11 23:12           ` Noah Lavine
2011-04-07 10:43 ` Hi! Interested in GSoC. Feedback on these ideas? Andreas Rottmann
2011-04-07 13:21   ` Paul Raccuglia
2011-04-07 21:45     ` Paul Raccuglia
2011-04-08  0:01       ` Paul Raccuglia
2011-04-08  1:00       ` dsmich
2011-04-08  4:36 ` Paul Raccuglia [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTikNNP1AGbOeuwMU4oAwK7eB5o3wJQ@mail.gmail.com \
    --to=praccugl@haverford.edu \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).