www/project_tasks.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<style type="text/css"> /* <![CDATA[ */
  @import "tigris-branding/css/tigris.css";
  @import "tigris-branding/css/inst.css";
  /* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
  href="tigris-branding/css/print.css"/>
<script type="text/javascript" src="tigris-branding/scripts/tigris.js"></script>
<title>What Needs Doing?</title>
</head>

<body>
<div class="app">

<h1 style="text-align: center;">What Needs Doing?</h1>

<p>There are a lot of different things you can do to help Subversion.
Not all involve coding; there are plenty of non-programming roles for
eager volunteers.</p>

<p>Below are some of the needs we've identified, but please don't take
these as gospel!  New volunteers bring fresh viewpoints, and one of
the most important things you can do is point out a need we hadn't
recognized before&nbsp;&mdash;&nbsp;and then fill it.</p>

<!-- ============================================================= -->
<div class="h2" id="information-management" title="information-management">
<h2>Information Management Tasks</h2>

<p>These are non-coding tasks, so if you arrived here from the <a
href="http://code.google.com/summerofcode.html">Google Summer of Code</a>
pages, please skip to later sections.</p>

<div class="h3" id="issue-management" title="issue-management">
<h3>Issue Management</h3>

<p>Do we need an Issue Manager?  Maybe...</p>

<p>The Subversion <a
href="http://subversion.tigris.org/project_issues.html">bug
database</a> has been managed in a rather ad hoc fashion thus far.
Periodically we make sweeps over all outstanding issues and try to
prioritize them, organize them into scheduled milestones, note
dependencies between issues, etc.  These methods have been moderately
successful up till now, but they are not scaling well as the number of
issues grows.  Since issue growth is proportional to user base growth,
the issue tracker is becoming a victim of Subversion's success.  We
need to find new ways of managing our issues, ways that do not involve
making O(N) sweeps over the entire list of open issues at regular
intervals.</p>

<p>While we have some semi-formalized management roles (patch manager,
release manager, etc), we have never had an issue manager.  It might
be time to get one, though.  It's not yet clear whether the problem is
mainly one of attention, or of algorithm, or both, but having someone
dedicated to managing the issues database couldn't hurt.  One thing
such a person could do would be to go through the list of outstanding
issues, figure out which ones are likely to be <a
href="#bite-sized">bite-sized tasks</a>, and mark them as such, so
that other volunteers have an easier time choosing things to work on.
We've already marked various issues as bite-sized, but we haven't done
so consistently as new issues come in.  This means there are a lot of
potential entry points to the project going unnoticed.  Want to help
us solve that?</p>

<p>Creative ideas welcome!  If you'd like to help with this, please <a
href="http://subversion.tigris.org/servlets/ProjectMailingListList"
>subscribe</a> to the <a
href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
mailing list and post your thoughts.</p>

</div>

<div class="h3" id="faq-management" title="faq-management">
<h3>FAQ Management</h3>

<p>We need a FAQ manager.  A FAQ manager is someone who stays
subscribed to the <a
href="mailto:users@subversion.tigris.org">users@subversion.tigris.org</a>
and <a href="mailto:dev@subversion.tigris.org"
>dev@subversion.tigris.org</a> mailing lists, watches for common
questions or addenda to existing questions, and slowly adjusts the
Subversion <a href="faq.html">FAQ</a> in response to the problems
users are having "in the wild".  This is also a great way to get
familiar with Subversion usage patterns and common problems.  If you
use or administrate Subversion anyway, helping to manage the FAQ is a
great way to expand your troubleshooting skills.</p>

<p>Again, creative ideas are most welcome.  Please post to the <a
href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
mailing list if you're interested in this.</p>

</div>

</div>

<!-- ============================================================= -->
<div class="h2" id="bite-sized" title="bite-sized">
<h2>Bite-Sized Coding Tasks</h2>

<p>The Subversion bug database contains many issues classified as
"bite-sized" tasks&nbsp;&mdash;&nbsp;tasks that are well-defined and
self-contained, and thus suitable for a volunteer looking to get
involved with the project.  You <i>don't</i> need broad or detailed
knowledge of Subversion's design to take on one of these, just a
pretty good idea of how things generally work, and familiarity with
the coding guidelines in the <a
href="http://svn.collab.net/repos/svn/trunk/HACKING">HACKING</a>
file.  Many tasks are things a volunteer could pick off in a spare
week or two, and they're a great way to start learning your way around
the Subversion code.</p>

<p> If you start one of these tasks, please notify the other
developers by marking the issue as "STARTED" in the issue tracker,
then mail <a
href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
(<a
href="http://subversion.tigris.org/servlets/ProjectMailingListList"
>subscribe</a> to that list too) with questions.  Don't be shy, it's a
very civil mailing list.</p>

<p>When you're ready to send in a patch, see the <a
href="http://subversion.tigris.org/mailing-list-guidelines.html#patches"
>patch posting guidelines</a>.  Don't be discouraged if your patch
goes through several iterations of review by other developers; this is
normal.</p>

<p>Here is the <a
href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&amp;issue_status=UNCONFIRMED&amp;issue_status=NEW&amp;issue_status=STARTED&amp;issue_status=REOPENED&amp;keywords=bite-sized&amp;cmdtype=doit"
>list of all bite-sized tasks</a>.</p>

</div>

<!-- ============================================================= -->
<div class="h2" id="larger-tasks" title="larger-tasks">
<h2>Larger (But Not Necessarily Huge) Coding Tasks</h2>

<p>The tasks listed below are bigger than bite-sized, but probably
don't require new research to solve.  In other words, most of them are
a <a href="http://www.catb.org/~esr/jargon/html/S/SMOP.html">Simple
Matter Of Programming</a>.  You'd need to either be, or be willing to
become, familiar with Subversion's internals to solve one of
these.</p>

<p>As with the <a href="#bite-sized">bite-sized tasks</a>, please read
the <a
href="http://svn.collab.net/repos/svn/trunk/HACKING">HACKING</a> file
and don't hesitate to ask questions on the
<a href="mailto:users@subversion.tigris.org">users@subversion.tigris.org</a>
and
<a href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
mailing lists (see <a
href="http://subversion.tigris.org/servlets/ProjectMailingListList"
>here</a> for subscription information).  Before posting any patches,
see the <a
href="http://subversion.tigris.org/mailing-list-guidelines.html#patches"
>patch posting guidelines</a>.</p>

<div class="h3" id="ra_svn_authn" title="ra_svn_authn">
<h3><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1144"
>Issue&nbsp;#1144</a>: Add Cyrus/SASL authentication support to
ra_svn (svn://)</h3>

<p>Right now ra_svn only supports the ANONYMOUS and EXTERNAL
authentication mechanisms.  This is enough to be useful (you can use
ssh for developers and daemon mode for anonymous read access), but
integrating Cyrus SASL would give users a multitude of other options:
passwords at various levels of security, Kerberos, one-time passwords,
etc..  The protocol is already designed to support SASL; this would
just be implementation work.</p>

</div>

<div class="h3" id="svnserve_authz" title="svnserve_authz">
<h3><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2316"
>Issue&nbsp;#2316</a>: Improve svnserve (svn://) authorization support</h3>

<p>It would be nice if ra_svn/svnserve had some form of path based
authorization, like mod_authz_svn provides when accessing repositories
via Apache.  Access should be controlled on a per-user/per-group
access with read and write access controllable for each user/group.
This should use the same config files as mod_authz_svn unless there is
a REALLY good reason not to.</p>

</div>

<div class="h3" id="ntlm-sspi" title="ntlm-sspi">
<h3><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1844"
>Issue&nbsp;#1844</a>: Subversion clients should be able to
authenticate using NTLM/SSPI</h3>

<p>We have a subversion/apache server configured to use sspi to
authenticate users.  Currently the svn client can't authenticate using
ntlm/sspi and uses basic authentication to connect to the server.
Users have to either store the credentials or enter them each time it
is needed.  It would be very convenient/secure if the subversion
client could use the current user's windows credentials to login to
subversion automatically without prompting the user.
The <a href="http://www.webdav.org/neon/">neon</a> lib has added sspi
support in revision 457 (2005-01-27).</p>

</div>

<div class="h3" id="error-messages" title="error-messages">
<h3><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1254"
>Issue&nbsp;#1254</a>, etc: Improve error messages</h3>

<p>Too many of Subversion's error messages are terse or confusing.
Many instances are recorded in
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1254"
>issue&nbsp;#1254</a>, but see also issues
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2302"
>#2302</a>,
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2295"
>#2295</a>, and
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2275"
>#2275</a>.</p>

</div>

<div class="h3" id="text-bases" title="text-bases">
<h3><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=525"
>Issue&nbsp;#525</a>
and <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=908"
>Issue&nbsp;#908</a>: Optional or compressed text base storage</h3>

<p>Subversion stores locally a pristine copy of the base revision
(i.e., the unmodified checked-out revision) of each file in the
working copy.  These pristine copies are known as "text bases".  This
is great for doing offline diffs, and for transmitting deltas back to
the server when committing.  But it's a bit of a space penalty on the
client side, and it would be nice to offer users the option to turn it
off sometimes, or failing that, to compress the text bases.  Doing
either or both would be a lot of work, but mostly straightforward
coding work.</p>

</div>

</div>

<!-- ============================================================= -->
<div class="h2" id="bindings" title="bindings">
<h2>Improved Bindings to Other Languages</h2>

<p>One of Subversion's strengths is that it offers a rich set of
"binding surfaces": well-documented APIs that are available not only
in C (Subversion's native language) but in other programming languages
as well (see the <a
 href="project_links.html#lang_bindings">complete list</a>).</p>

<p>Some of these language bindings are maintained via <a
href="http://www.swig.org/">SWIG</a>, a tool that partially automates
the process of generating bindings, while others are maintained by
hand.  Many of the bindings do not have complete coverage yet, or have
interface problems where they do have coverage.  So even though
they're used in many production systems, there's still plenty of work
to do.  Specifically:</p>

<ul>

<li><p>The <a
href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/python/"
>SWIG/Python bindings</a> are in pretty good shape, but their coverage
is not yet complete.  Help is welcome.</p></li>

<li><p>The <a
href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/ruby/"
>SWIG/Ruby bindings</a> were just started, and could use a lot of
help.</p></li>

<li><p>Our <a
href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/java/javahl/"
>Java</a> and <a
href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/perl/"
>SWIG/Perl</a> bindings are in pretty good shape, but maybe there are
other languages you'd like to call Subversion APIs from?  Lisp/Scheme?
Feel free to start a new bindings project, if you don't see what you
need here.</p></li>

</ul>

</div>

<!-- ============================================================= -->
<div class="h2" id="all-issues" title="all-issues">
<h2>All Open Issues</h2>

<p>You want to see the complete list of open bugs, in all its glory?
Don't say we didn't <a
href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&amp;issue_status=UNCONFIRMED&amp;issue_status=NEW&amp;issue_status=STARTED&amp;issue_status=REOPENED&amp;order=issues.target_milestone%2C%20issues.priority%2C%20issues.issue_type">warn you...</a></p>

</div>

</div>
</body>
</html>