[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Feature-by-feature evaluation of v1.5

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 07 Mar 2008 16:41:24 +0000

As part of evaulating the readiness of v1.5 for release, I want to tease out
any real concerns about the usability of the current features that are
troubling people.

Ideally, we'll be able to get at least one or two people to conduct a very
high-level review of each significant feature. The aim is to understand and
write down the limitations of the feature from a user's point of view, ignoring
our knowledge of the project's history and how the software works. Note any
improvements that are desirable but don't block it from release. I expect most
of the concerns can be satisfied by documenting the restrictions in a positive
way, but in the extreme case of us deciding that some aspect of a feature is
currently more harmful than good we can consider disabling that aspect.

Here's a suggested list of features to look at [1]:

   # Merge Tracking
   # Sparse checkouts
   # Copy/move-related improvements
   # Interactive conflict resolution
   # WebDAV transparent write-through proxy
   # Cyrus SASL support for ra_svn and svnserve
   # Changelist support
   # Relative and peg URLs in svn:externals
   # FSFS sharding
   # Easier to try out experimental ra_serf DAV access module

The sort of thing I'm thinking of would be to make just a few notes about each
of the following:

   - Look from both a new user's and a power user's point of view.

   - Where is the feature documented, and to what extent?

   - How clearly does the documentation (book, web, built-in help) state what
to expect from the feature and how to use it safely, so that the user's
expectations are set appropriately? Are the boundaries for successful use
reflected in the help, the error messages, and the general usability?

   - How complete is the feature?

   - Does the feature behave well enough, within its limitations, for users to
be happy with using it in its current state?

   - Can we see a good upgrade path for its limitations?

   - Are there any ways of using it that will likely cause problems in the
future, or that lead to results that are so nasty that we'd be better off
disabling those cases for the time being?

Could you - anyone - volunteer to do this for one of the features?

Remember, we are in the position of having a lot of good features that we're
nearly ready to release, so try not to be overly critical of what we've
created. Look only for practical things we might need to do right now to avoid
leading ourselves into trouble.

- Julian

[1] Taken from Eric's "Technology Preview" email
<http://svn.haxx.se/dev/archive-2008-02/0807.shtml> which includes some of his
concerns on some of them.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-07 17:41:43 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.