Matt [Danger]

Google began accepting applications for the Summer of Code yesterday and we’ve been busy on the Geeklog IRC channel answering student questions and reading proposals.

Here are some things to remember when writing a proposal for the Summer of Code:

Understand the organization you’re applying to work with
Before you spend any time writing a proposal you need to understand the organization, software, and problem you’re working on. Download the latest version of the code and read through some of it. Install and use it. Look at the documentation. See what the software can and can’t do and how it applies to your project.

Write a good proposal!
After you’ve looked through the code and feel you have a good understanding of the problem then you can sit down and start writing. Your proposal should include all the points of the problem, why they’re a problem, how you’re going to address the problem, and how your solution to the problem will benefit the organization.

Only write a few proposals
A good proposal takes a long time to write. You need to fully understand the problem and the organization before writing a good proposal. You may think that writing a bunch of proposals for many different organizations will increase your odds of being selected, but instead you’re just decreasing the quality of your proposals and reducing your chances of being selected.

Ask questions
Mentors are hanging out on IRC all day waiting for you to ask them questions. We’re excited to do it because we get to see the interest in our organization. We’d also be glad to look over your proposal and provide feedback before you submit it to the SoC.

To give students an example of what a proposal should look like I’m going to post my proposal from last year. Unfortunately, I can’t find the one from 2007 that I think is a little better.

Abstract

The Geeklog installation wizard makes setting up a new, or upgrading an
existing, Geeklog site a quick and painless process. However, there are
two situations where a website administrator must still perform tasks
manually: managing plugins and migrating from a backup. My proposal is
to add a plugin management utility that will be rolled into the
installation process and will allow direct control of plugins as well as
a migration utility that will give the user the ability to restore
Geeklog from a backup seamlessly.

PROJECT DETAILS – PLUGIN FEATURE

The plugin installation process will be made steamless for the user. An
“Advanced Installation Options” link will appear underneath what is
currently the install configuration options form on page 2 of the
installation and when clicked will take the user to a separate page to
manage plugins (and migration, which will be discussed in the next
section). The list of plugins will be populated by listing the contents
of Geeklog’s plugins directory. A file upload form will give the user a
simpler method of uploading the plugin, which will require the plugins
directory be write-able by the web server. By default all of the plugins
inside the plugins directory will be installed, unless the user chooses
to not install them. The plugins that are selected for install will be
sent with the rest of the form data from step 2 to step 3 of the
installation wizzard where each plugin’s installation script is executed.

The plugin installation during the upgrade process will be similar to
the new installation process described in the previous paragraph. If a
newer version of an installed plugin exists the plugin will be
automatically upgraded. The user will still be given the ability to
install new plugins during the upgrade in the same way as a fresh install.

In addition to the installation wizard, the plugin management panel
inside the administration area will be modified to add the ability to
upload a plugin which will make adding new plugins quicker.

For users who wish to create a custom Geeklog distribution with their
own favorite plugins a simple stand alone utility will be developed.
This will consist of a single PHP shell script that downloads and
decompresses the Geeklog tarball and lists the contents in the plugins
directory. The user will be have the ability to deselect and remove any
of the listed plugins and also given the ability to add additional
plugins by either copying a plugin tarball, or directory, from another
directory on the local machine or specifying a URL to the plugin tarball
on a remote server. After the user makes selects the plugins they want
the entire geeklog directory will be recompressed with the new plugins.
All the plugins in the plugins directory will be installed by default,
unless unselected by the user, during install.

PROJECT DETAILS – MIGRATION ASSISTANT FEATURE

Geeklog currently has a backup feature which creates a SQL table scheme
and data file. This file will be used as a restore point for the
migration feature.

The option to migrate from backup will be added to the “Advanced
installation options” area proposed above for plugin installation. In
this area a checkbox to “Import from backup” will appear with the option
to select an existing backup from the backups/ directory or to upload a
backup file. A message will be displayed to users to warn them about
possible timeout issues when uploading large files and that they may
want to upload their file via FTP to the backups directory instead.

Once a backup file is selected the migration process will import the
database table schema and data from the backed up SQL file. Some
additional analysis will need to be taken during this step so that large
database imports do not exceed the web server’s maximum script runtime.
A possible solution would be to perform a staggered import, where the
import process is broken into smaller pieces. Dirk has suggested a
utility called BigDump which does this for MySQL. We might be able to
simply implement that utility with a modification to allow it to also
work with MS SQL.

After the database has been imported the script will query the
‘conf_values’ table to ensure the stored paths match the new system
paths. If they do not they will be updated based on the data from the
installation form or the user will be prompted to define the path. This
is similar to a fresh installation where all paths must be set. The last
step will be any remaining checks to ensure all necessary database
information exists, that required plugins exist (if they don’t they will
be disabled in the database until the user installs them) and the
correct system files are in place.

Finally, the Geeklog upgrade documentation makes a strong recommendation
that the user backup their database before attempting to upgrade, so why
don’t we offer to do this for them? An option will be added during the
upgrade process to ask the user if they’d like us to backup their
existing installation. This will not be selected by default because of
the time it would add to an upgrade. If selected a backup of the
database will be saved to the backups directory before updates are performed.

BENEFITS

- Plugin installation steps will be reduced and will require no command
line access of file editing resulting in fewer sources of user error.
- Migration feature would give users the ability to easily and reliabily
restore from backups without remote shell access.
- Automatic backup option before performing an upgrade will create a
quick and simple restore option for users that experience a problem in
the upgrade process.

TIMELINE

Week 1: Checkout latest GL package and start evaluating the code base
Week 2: Final plugin installation and migration assistant format design
Week 3-4: Code furiously, develop unhealthy caffeine and energy drink
dependence
Week 5: Rough working plugin installation feature
Week 7: Rough working migration assistant feature
Week 8: Midterm, submit code for evaluation
Week 9: Make revisions based on any mentor suggestions
Week 11: Major work complete on plugin installation feature, submit to CVS
Week 12: Major work complete on migration assistant feature, submit to CVS
Week 13: Begin to complete documentation and testing
Week 14: Iron out final bugs
Week 15: Submit all deliverables for evaluation

DELIVERABLES

- Plugin installation/management added into installation script
- Plugin installation/management added to administration panel
- Stand alone command line utility to create custom Geeklog distributions
- Migration feature added into installation script
- Additional English localization entries
- Additional install documentation

ABOUT ME

I am a 23 year old graduate student at D’Youville College in Buffalo,
NY, USA. I enjoy programming for the web but more importantly I love
creating a rich experience for those who use my software. I have
previously worked with Geeklog in the 2007 Summer of Code program and
the experience was invaluable. I had an incredible time and hope to be a
participant again this year! I believe I am the best applicant for this
project because I wrote and am deeply familiar the current installation
wizard script.