Hi,
Over the last two weeks I have received a large number of emails
regarding OpenSSH's participation in the 2009 Google Summer of Code
program.
This email should answer the questions that you collectively asked.
Please forgive this bulk reply - there are simply too many of you to
reply to individually. If I have failed to answer your question, please
feel free to email me again.
If you haven't already done so, please read the GSoC FAQ:
http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs
Here are the answers to your questions:
1. Applications
Quite a few of you sent applications to participate to me directly. I'm
not able to act on these unless they are made though the application
tool on the GSoC website http://socghop.appspot.com/ so please make your
application there.
2. Decision criteria
When assessing the applications the things that I will be looking for
will be:
1) A demonstration of understanding of the problem/idea that the student
has chosen.
2) Evidence that they have the necessary skills to take it on. This may
take the form of prior free software contributions, patch submissions
or code samples that I can look at. Academic experience alone is
likely to be insufficient.
3) A good schedule of tasks to implement the idea and a realistic
time-line for completing them. We *strongly* favour decomposition of
work into smaller units that can be reviewed and completed
independently and it is not a coincidence that the ideas that we have
listed can be broken down in this way.
Students who go a little beyond the stated requirements (e.g. by
including "stretch goals") while still remaining realistic in their
proposals will be preferred.
3. Start date
The official GSoC start date for contributors is May 23, but some of you
have asked about starting early. Students starting the actual work early
is OK, but I think there is some advantage of familiarising oneself with
the project, its source code, practices and culture first. The GSoC
includes two months of "Community Bonding Period" to facilitate this,
but if the student feels that they are ready sooner then that is OK.
4. Level of commitment
Some of you asked about how of your time you would have to dedicate
to work on GSoC projects. This is completely up to you! You should
decide your own level of commitment and base your proposals around
that. Obviously, students with more ambitious proposals will have some
advantage (so long as they are realistic), but we certainly don't want
to burn you out and sour your experience with free software development.
5. Assessment
This being the first time OpenSSH has participated in GSoC, I'm ignorant
of what criteria the program will ask us to use when evaluating
students' work. From my perspective, the main criteria will be "how
much
have they improved OpenSSH?" Bear in mind that improving OpenSSH means
getting code completed, reviewed and committed to our CVS repository
6. Specific projects
Many of the questions were about the specific ideas that we had listed
on http://www.openssh.com/gsoc.html so here is some more detail on each:
6.1 Renovate sftp
The motivation for this idea is to make sftp(1) a compelling replacement
for scp(1). scp(1) has a very easy to use command-line interface,
supports recursive copies ("scp -r") and is quite fast - it does not
need a server round-trip for each file that it copies. Unfortunately
scp(1) is unmaintainable - its protocol practically requires shell
access and has no backwards compatibility or extensibility support.
So this project would be adding these missing features to sftp(1) and
exposing them via a commandline that is as compatible with scp(1)'s as
possible. Beyond this baseline, there are a number of other things that
may be done to improve sftp(1):
- Implement tab-completion in interactive mode. Ben Lindstrom has written
a patch to implement this, and it only needs a tiny amount of work to
get it committed.
- Improve the interactive interface. Right now, things like
"get file1 file2 file3" don't work, or don't do what one
might normally
expect.
Also, the sftp client currently requires read access to every
component of the patch in which it is operating (i.e. traverse-only
directories break it) - there is no protocol-level reason why this needs
to be the case so this could be fixed fairly easily too.
6.2 Improved testing infrastructure
There weren't too many questions on this. I hope the description given at
http://www.openssh.com/gsoc.html#testing was enough explanation to get
someone started.
6.3 Performance improvements
There are three main metrics by which OpenSSH's performance may be measured
when performing some operation such as transferring a directory of files,
connect to a server or moving a fixed quantity of data:
- How long does it take?
- How much CPU time does it take?
- How much memory does it take?
Environmental considerations can affect these, especially network latency.
Over the last couple of releases, we have worked to improve transfer speed
on high bandwidth*delay links as well as general CPU performance, but
there is certainly more that can be done especially in the area of memory
consumption.
The first step would be to develop some good benchmarks that measure
various aspects of OpenSSH's performance. Ideally, these should be able
to be run alongside the standard suite of regression tests so we can
ensure that we do not regress performance-wise in the future.
>From there, the student would need to identify and fix performance
bottlenecks or waste.
There is an external project
http://www.psc.edu/networking/projects/hpn-ssh/ that has conducted quite
a bit of work on making OpenSSH faster which a student could use as a
resource.
6.4 Other projects
There were a couple of people who suggested writing GUI frontends to
parts of OpenSSH. This might be a good idea, but its not something
that we would accept as a GSoC project - we aren't likely to ever ship
GUI tools in OpenSSH and I personally lack the necessary experience to
properly assess contributions in this area.
----
Thank you all very much for your interest, and please feel welcome to
send any additional questions to myself or to the public OpenSSH mailing
list: https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Regards,
Damien Miller