Progressing JCSP

[Russel Winder]

Hi,

As some of you may already have heard, Jon Kerridge's Groovy Parallel is
being incorporated into the GPars project (http://gpars.codehaus.org) so
as to provide the Groovy/Java world with an easy CSP capability. Of
course this means JCSP is going to be more widely needed since Groovy
Parallel is a wrapper around JCSP.

This means that we need to get JCSP into the Maven repository, and also
begin the move to arrive at a 1.1 final release. And then a 1.2,
1.3, . . . but getting a JCSP artefact (or two) into the Maven
repository is the primary need just now.

Given the GPars/Groovy situation, the easiest way of getting JCSP into
the Maven repository is to have a Codehaus project JCSP, and I have
already applied for this project on behalf of Peter Welch, all of you
and all the GPars team. If the request is successful then we will get a
Git repository, a JIRA issue tracker, and a Bamboo continuous
integration service (*). The intention is for this Git repository to be
a mirror of the Kent Subversion repository, not for it to be a fork.
Two issues though:

1. There needs to be a way of building an OSGi-fied jar as an artefact
for submission into the Maven repository -- though it may be that there
are two different jars as artefacts (which militates in favour of using
Gradle not Maven, see below).

2. People other than those with write access to the Kent Subversion
repository will want to use version control, and create changesets.

To deal with 1, I am going to propose not introducing use of the Maven
Ant task into the Ant build (though this is a backup plan) but instead
to create either a Gradle or Maven build -- we here in GPars land almost
certainly prefer Gradle for really Groovy reasons, but if Maven works
better for people then that works for me, assuming we can get two
artefacts out of it, which may not be easy (whereas it is with Gradle).
This new JCSP build could either be maintained in a branch in the
Codehaus Git repository or offered back into the Kent trunk branch.
Which leads to 2.

People outside the set of people with write access to the Kent
Subversion repository will need a way of offering back patches and merge
requests. Most people will use Bazaar, Mercurial or Git so there needs
to be a bridge and a process for submitting things. Codehaus projects
generally use their JIRA issue trackers for this, but maybe this won't
work for the JCSP development process at Kent?

Does this lead to any thoughts?

Thanks.

(*) Though looking at the current JCSP source I don't see much in the
way of unit tests, just the demos :-(

[Adam Sampson]

Hi Russel,

Post by Russel Winder
2. People other than those with write access to the Kent Subversion
repository will want to use version control, and create changesets.

I would strongly prefer to give them write access to the existing
project, rather than forking the project. While the JCSP development
infrastructure is mostly hosted at Kent, it's not been an
exclusively-Kentish project for a very long time (if ever?).

Our project hosting service was carefully designed to give the same
rights to all users regardless of whether they're at Kent or not. If
someone comes along and wants to contribute to JCSP, all they need to do
is to create a CSProjects account (http://projects.cs.kent.ac.uk/) and
ask to be added to the project; if you don't want to let them commit to
trunk right away, it's easy to give them a private branch.

Post by Russel Winder
Codehaus projects generally use their JIRA issue trackers for this,
but maybe this won't work for the JCSP development process at Kent?

JCSP (like all projects on CSProjects) already has a Trac installion for
issue tracking. We can also tie automated testing into CSProjects; we
use buildbot on several projects already, but it's straightforward
enough to add hooks for something different. As far as I know, the only
reason the JCSP developers haven't set up a buildbot for JCSP yet is
that it doesn't *have* any unit tests...

Thanks,

[Russel Winder]

Adam,

I wrote my earlier email to Peter before reading this, sorry about that.
It means some of the questions posed there are part answered here.

Post by Adam Sampson

Post by Russel Winder
2. People other than those with write access to the Kent Subversion
repository will want to use version control, and create changesets.

I would strongly prefer to give them write access to the existing
project, rather than forking the project. While the JCSP development
infrastructure is mostly hosted at Kent, it's not been an
exclusively-Kentish project for a very long time (if ever?).

I guess I have a problem with centralized version control. I am now
used to distributed version control (DVCS), and it's branch and merge
strategy which is so problematic in Subversion even in 1.6 (as it is a
versioned filestore not a project version control system). Forking is
an interesting issue as in the DVCS world every branch is a fork!
Clearly we must avoid any thought of a project fork, there must only be
one JCSP! However Subversion can be a real barrier.

The core issue is for small contributions. If people can make a
contribution without having to go through all the hassle of signing up
for write access to a central repository then that is good. It widens
the pool of potential contributors. Currently, Bazaar and Git can be
used as clients to Subversion. Indeed this is the only way I work with
Subversion these days as it gives me a branch and merge capability that
is just so much hassle using Subversion.

Now whilst Git can only be used as a personal client to Subversion,
Bazaar allows for smooth interworking of people using Bazaar and people
using Subversion centred on a single Subversion repository. Whether
this move to using Bazaar and retaining the Subversion repository is
interesting is yes for me but may not be for others.

If there is any use of Bazaar it would be wise to set up a project on
Launchpad. Actually I will do this anyway as a form of guerilla
marketing. OK, it is another set of bug trackers and such like but they
can all be pointed back at Kent.

Post by Adam Sampson
Our project hosting service was carefully designed to give the same
rights to all users regardless of whether they're at Kent or not. If
someone comes along and wants to contribute to JCSP, all they need to do
is to create a CSProjects account (http://projects.cs.kent.ac.uk/) and
ask to be added to the project; if you don't want to let them commit to
trunk right away, it's easy to give them a private branch.

I guess I am repeating myself but the "sign up and checkout using
Subversion" (especially the sign up) is increasingly seen as a barrier
to wide participation. What I have seen in the DVCS-using community is
that people can take a branch, work on it for some problem, submit a
patch, and never be seen again. This hasn't stopped the patch being
excellent and immediately committed by someone with write access. This
model works especially when organizing sprints in and around
conferences.

I guess the issue is how open or closed the JCSP community should be.
I guess I am for total openness of open source projects where Subversion
creates two classes of people -- no matter how easy it is to obtain
write access. In complete conflict with this, I am for tight control of
HEAD so as to ensure it always builds and always does what it claims to
do. Having a chaotic commit model as Subversion requires and Bazaar,
Mercurial and Git allow can be a real problem. DVCS systems allow for
much more rigid control over HEAD that is possible with Subversion.
"Management" is increasingly coming to like this for obvious reasons!

Post by Adam Sampson

Post by Russel Winder
Codehaus projects generally use their JIRA issue trackers for this,
but maybe this won't work for the JCSP development process at Kent?

JCSP (like all projects on CSProjects) already has a Trac installion for
issue tracking. We can also tie automated testing into CSProjects; we
use buildbot on several projects already, but it's straightforward
enough to add hooks for something different. As far as I know, the only
reason the JCSP developers haven't set up a buildbot for JCSP yet is
that it doesn't *have* any unit tests...

OK this sounds as though we should keep the Codehaus infrastructure to
an absolute minimum and always point people at the Kent stuff. In
effect the sole purpose of the Codehaus project is to create a route to
the Maven repository entirely within the control of the JCSP community.
This was my original intention anyway so no problems there!

Buildbot is good :-) Where is the public webpage?

I haven't used Trac much but if it is already there then it should be
used in preference to setting up JIRA issues. Where is the public
webpage?

A corollary is that perhaps http://www.cs.kent.ac.uk/projects/ofa/jcsp/
needs to be made into a portal for all the project-related goodies.
Currently it presents itself more as a site to advertise the academic
papers, which is almost certainly intentional originally, but is likely
a bit of a turn-off for non-academics who just want to know about the
mechanics of contributing to the project and the codebase.

[Chalmers, Kevin]

Hi Russel,

The core issue is for small contributions. If people can make a contribution
without having to go through all the hassle of signing up for write access
to a central repository then that is good. It widens the pool of potential
contributors. Currently, Bazaar and Git can be used as clients to Subversion.
Indeed this is the only way I work with Subversion these days as it gives me
a branch and merge capability that is just so much hassle using Subversion.

The Subversion method works quite well for the work on JCSP as there are particular features of the library that have to avoid modifications without really well founded reasons. Parts of the library are formally verified to ensure correct operation, and without some semblance of control, features can become broken. Contribution is normally done via researchers who are actively publishing their work in the area. Typically, we have been working on individual branches which are then proposed as additions to the main trunk. As an example, my net2 library is called net2 because of the existing net package. This has been discussed, and we will likely be removing net and replacing it with net2 once we are sure no one is badly affected.

JCSP as a project is fully open sourced, and anyone can check it out and modify as they wish. The core functionality is solid, and although updates are required in sections (see Peter's previous email), the only project that would have an effect on the core as is would be a move to using the Java 1.5 concurrency constructs. Other projects are usually about additional functionality being added after some scrutiny, or wrappers around the core to support some library (see the AWT library).

The core issue is for small contributions.

I guess the main problem of a DVCS from our point of view is who will monitor the updates and commit them. As Peter pointed out, there has never been actively funded support for JCSP to pay for someone to undertake this task. All credit to Adam and the others at Kent who have built the system that exists and maintaining it on top of their other tasks, as it has made my job, and many others, a lot easier. If there was actively funded support, then maybe a DVCS system becomes more viable. However, that is a decision that would have to be made by the project owners.

Kevin

-----Original Message-----
From: Russel Winder [mailto:***@concertant.com]
Sent: 13 February 2010 10:14
To: Adam Sampson
Cc: Kent POP Developers; GPars Developers; Kerridge, Jon; Chalmers, Kevin
Subject: Re: [pop-dev] Progressing JCSP

Adam,

I wrote my earlier email to Peter before reading this, sorry about that.
It means some of the questions posed there are part answered here.

Post by Russel Winder
2. People other than those with write access to the Kent Subversion
repository will want to use version control, and create changesets.

I would strongly prefer to give them write access to the existing
project, rather than forking the project. While the JCSP development
infrastructure is mostly hosted at Kent, it's not been an
exclusively-Kentish project for a very long time (if ever?).

I guess I have a problem with centralized version control. I am now used to distributed version control (DVCS), and it's branch and merge strategy which is so problematic in Subversion even in 1.6 (as it is a versioned filestore not a project version control system). Forking is an interesting issue as in the DVCS world every branch is a fork!
Clearly we must avoid any thought of a project fork, there must only be one JCSP! However Subversion can be a real barrier.

The core issue is for small contributions. If people can make a contribution without having to go through all the hassle of signing up for write access to a central repository then that is good. It widens the pool of potential contributors. Currently, Bazaar and Git can be used as clients to Subversion. Indeed this is the only way I work with Subversion these days as it gives me a branch and merge capability that is just so much hassle using Subversion.

Now whilst Git can only be used as a personal client to Subversion, Bazaar allows for smooth interworking of people using Bazaar and people using Subversion centred on a single Subversion repository. Whether this move to using Bazaar and retaining the Subversion repository is interesting is yes for me but may not be for others.

If there is any use of Bazaar it would be wise to set up a project on Launchpad. Actually I will do this anyway as a form of guerilla marketing. OK, it is another set of bug trackers and such like but they can all be pointed back at Kent.

Our project hosting service was carefully designed to give the same
rights to all users regardless of whether they're at Kent or not. If
someone comes along and wants to contribute to JCSP, all they need to
do is to create a CSProjects account (http://projects.cs.kent.ac.uk/)
and ask to be added to the project; if you don't want to let them
commit to trunk right away, it's easy to give them a private branch.

I guess I am repeating myself but the "sign up and checkout using Subversion" (especially the sign up) is increasingly seen as a barrier to wide participation. What I have seen in the DVCS-using community is that people can take a branch, work on it for some problem, submit a patch, and never be seen again. This hasn't stopped the patch being excellent and immediately committed by someone with write access. This model works especially when organizing sprints in and around conferences.

I guess the issue is how open or closed the JCSP community should be.
I guess I am for total openness of open source projects where Subversion creates two classes of people -- no matter how easy it is to obtain write access. In complete conflict with this, I am for tight control of HEAD so as to ensure it always builds and always does what it claims to
do. Having a chaotic commit model as Subversion requires and Bazaar,
Mercurial and Git allow can be a real problem. DVCS systems allow for much more rigid control over HEAD that is possible with Subversion.
"Management" is increasingly coming to like this for obvious reasons!

Post by Russel Winder
Codehaus projects generally use their JIRA issue trackers for this,
but maybe this won't work for the JCSP development process at Kent?

JCSP (like all projects on CSProjects) already has a Trac installion
for issue tracking. We can also tie automated testing into CSProjects;
we use buildbot on several projects already, but it's straightforward
enough to add hooks for something different. As far as I know, the
only reason the JCSP developers haven't set up a buildbot for JCSP yet
is that it doesn't *have* any unit tests...

OK this sounds as though we should keep the Codehaus infrastructure to an absolute minimum and always point people at the Kent stuff. In effect the sole purpose of the Codehaus project is to create a route to the Maven repository entirely within the control of the JCSP community.
This was my original intention anyway so no problems there!

Buildbot is good :-) Where is the public webpage?

I haven't used Trac much but if it is already there then it should be used in preference to setting up JIRA issues. Where is the public webpage?

A corollary is that perhaps http://www.cs.kent.ac.uk/projects/ofa/jcsp/
needs to be made into a portal for all the project-related goodies.
Currently it presents itself more as a site to advertise the academic papers, which is almost certainly intentional originally, but is likely a bit of a turn-off for non-academics who just want to know about the mechanics of contributing to the project and the codebase.
--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: ***@russel.org.uk
Concertant LLP t: [phone], [phone]
41 Buckmaster Road, f: [phone] voip: sip:***@ekiga.net
London SW11 1EN, UK m: [phone] skype: russel_winder

On 25 February 2009, the University launched its new name, Edinburgh Napier University.

For more information please visit our website.

Edinburgh Napier University is one of the top 10 universities in the UK for graduate employability (HESA 2009)

This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else out-with the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

Edinburgh Napier University is a registered Scottish charity. Registration numbe

[Russel Winder]

Kevin,

Apologies for the delay in replying.

Post by Chalmers, Kevin
The Subversion method works quite well for the work on JCSP as there
are particular features of the library that have to avoid
modifications without really well founded reasons. Parts of the
library are formally verified to ensure correct operation, and without
some semblance of control, features can become broken. Contribution
is normally done via researchers who are actively publishing their
work in the area. Typically, we have been working on individual
branches which are then proposed as additions to the main trunk. As
an example, my net2 library is called net2 because of the existing net
package. This has been discussed, and we will likely be removing net
and replacing it with net2 once we are sure no one is badly affected.

Regarding protection of bits of source code, it is not so much a case
of which tool to use (Subversion, Bazaar, Mercurial, Git, etc.) but how
the team with commit capability work. It is a social, trust and team
issue. If Subversion and centralized version control, where everyone
taking a branch has commit rights and all committers are trusted not to
damage the source, or the Subversion repository manager sets up detailed
fine-grain control of directories and files, works for the team then
that is fine. I believe though there is a tension between the branch
and merge approach and the use of Subversion.

I would suggest that an equivalent centralized workflow using a
distributed version control system would actually improve things, in
particular it would provide better support for the branch and merge that
is already a part of the workflow. Bazaar in particular, but also
Mercurial and Git, can be used as better centralized version control
systems for projects. Same workflow, better tool.

Post by Chalmers, Kevin
JCSP as a project is fully open sourced, and anyone can check it out
and modify as they wish. The core functionality is solid, and
although updates are required in sections (see Peter's previous
email), the only project that would have an effect on the core as is
would be a move to using the Java 1.5 concurrency constructs. Other
projects are usually about additional functionality being added after
some scrutiny, or wrappers around the core to support some library
(see the AWT library).

I am very confident in JCSP being the framework to bring CSP to the JVM.
The library has been around only a little less long than Java and the
JVM itself, and as you say, during that time, the core has become solid.
Clearly though a library must evolve as the platform evolves, so as to
be in tune with the programming idioms appropriate on the platform of
the time.

In this respect I am currently trying to formulate sensible questions,
backed up with examples, about the dependence on using primitive arrays.
Modern Java programming idioms favour the use of Collections rather than
primitive arrays, but the JCSP API seems awkward to use with ArrayLists,
etc. -- though this may be that I am not using the API in a sufficiently
sophisticated way. Also there is the issue of using the JCSP API from
Scala, where the idiomatic data structures are different again. And
indeed JCSP should be usable from JRuby and Jython. Groovy is of course
being dealt with by GPars integrating Jon's work.

Other questions I hope I am going to be able to dig at are whether JCSP
depends on having a single JVM or whether it can work with a cluster of
JVMs. Alex Tkachman has added cluster capability to the GPars actors
infrastructure, so we need to make sure that the CSP support in GPars
has the same multicore and cluster support.

Post by Chalmers, Kevin
I guess the main problem of a DVCS from our point of view is who will
monitor the updates and commit them. As Peter pointed out, there has
never been actively funded support for JCSP to pay for someone to
undertake this task. All credit to Adam and the others at Kent who
have built the system that exists and maintaining it on top of their
other tasks, as it has made my job, and many others, a lot easier. If
there was actively funded support, then maybe a DVCS system becomes
more viable. However, that is a decision that would have to be made
by the project owners.

I am not sure DVCS is actually a problem here compared to CVCS. In fact
you can use DVCS tools to create a CVCS workflow but with far superior
branch and merge support. Also disconnected working -- which is
important when on planes, trains and automobiles, not to mention in
hoptels without sensible Internet connections. If I were creating a
centralized repository for a project today I would use Bazaar rather
than Subversion -- still CVCS workflow and management, but a better
tool.

I think there is an update and monitoring issue whether you are using
DVCS or CVCS: the update and monitoring that is more obviously
happening in a distributed workflow is still a responsibility in a
centralized workflow, but sometimes is just not done. Subversion on the
one hand, and Bazaar (Mecurial and Git) on the other, just have
different tools for achieving things like fine-grained control over who
can commit to which files.

The point here though is not so much what is best per se according to
some metrics, but what people giving their time free to the project are
prepared to do. As you say Adam and others have set up
Subversion/Trac/Buildbot because that is what they were prepared to do.
If that works, and there is no "point of pain" and no desire to change
amongst the active team members then that is fine. There is an
equilibrium.

Because of the GPars "point of pain", I have added to the extant
infrastructure a mirror Git repository purely to get a JCSP artefact
into the Maven repository. As I have time I am ensuring that there is
no independent infrastructure at Codehaus and that where there is
something publicly viewable it points back to the Kent infastructure.
Thus there will be no Codehaus developers, no Codehaus bug reporting,
and no Codehaus JCSP-related mailing lists -- though as and when there
is a unit test or system test infrastructure in JCSP I may well make use
of the Bamboo CI service at Codehaus. For now there is one, and only
one way, of amending the Git repository and that is for me to push
things. Currently there is an additional branch that contains the Maven
POM on Subversion HEAD, but that is the only difference to the
Subversion repository. I am going to experiment with using Gradle
rather than Maven to build the artefact and inject into the Maven
repository, but the POM and the Gradle build file will be the only
differences between Kent's Subversion and the Git repository at
Codehaus.

If the JCSP team wish to bring all this Maven-related stuff "in house"
and have all the materials to create and inject artefacts into the Maven
repository in Subversion HEAD, then that works for me. Then the
Codehaus repository becomes just the way of publishing the artefacts.
Although this is not actually needed, it is a far, far simpler route
than any of the others, and as it is now in place, it is probably best
to continue to use it.

There is one question though that needs the JCSP team to voice and
opinion -- or for Peter to make his decision known. Currently I am
publishing Subversion HEAD to the Maven snapshot repository as
"org.codehaus.jcsp:jcsp:1.1-rc5-SNAPSHOT" pending any publishing
decision. Should I also publish the 1.1-rc4 release to the main Maven
repository?

[Adam Sampson]

Hi Russel,

Post by Russel Winder
If the JCSP team wish to bring all this Maven-related stuff "in house"
and have all the materials to create and inject artefacts into the
Maven repository in Subversion HEAD, then that works for me.

That sounds like a sensible approach to me. What can we do right now to
help you with this?

Post by Russel Winder
Currently I am publishing Subversion HEAD to the Maven snapshot
repository as "org.codehaus.jcsp:jcsp:1.1-rc5-SNAPSHOT" pending any
publishing decision. Should I also publish the 1.1-rc4 release to the
main Maven repository?

I think publishing both versions would be a good idea, assuming it's not
too much additional work; as I understand it, some of the documentation
and examples in the trunk haven't yet been updated to match the most
recent API changes, so users may have good reasons for sticking with
the last release for now.

Thanks,

[Russel Winder]

Adam,

Post by Adam Sampson
Hi Russel,

Post by Russel Winder
If the JCSP team wish to bring all this Maven-related stuff "in house"
and have all the materials to create and inject artefacts into the
Maven repository in Subversion HEAD, then that works for me.

That sounds like a sensible approach to me. What can we do right now to
help you with this?

Currently, I have a branch of trunk ('mavenBuild') which has the POM as
the only change and a branch of the 1.1-rc4 tag ('1.1-rc4') which has a
copy of the POM but a different version number, again as the only
change. Options to get one or both into trunk would seem to be:

1. I send the POM file(s) as an attachment and someone with write
permission adds it to trunk. I maintain my branches and ship back
patches as and when.

2. Someone with write permission to the Subversion repository creates a
Git client of Subversion trunk (which is what I have done), pulls the
changes from my repository (or more likely the Codehaus repository) and
then merges them into Subversion trunk. (Easy for me to say and do, but
possibly people without any Git experience would prefer Route 1.)

3. I get write permission and add and maintain the POM in the
Subversion repository.

but it may be that merging the POM into trunk is not the best future.
This probably needs some cogitation amongst the POP developers.

I believe that Gradle or Maven would be better than Ant as the
build/project management tool for JCSP, but there may be a reason for
using Ant that I am not aware of.

Normally I would prefer Gradle over Maven, but in this case it was
quicker to use Maven. Now that there is something in the snapshots
Maven repository and I can do my demos at next weeks conference, there
is time for reflection -- so perhaps it is premature to put the POM into
trunk? Do the JCSP development people want to consider transitioning to
using Gradle or Maven as the build/project management tool? If so then
a Gradle build file or the Maven POM can be developed more fully --
which I would be happy to do, especially if Gradle is the choice.

Although Gradle is a bit less mature than Maven it is still usable for
production work. It's big advantage for JCSP is that it handles
multiple artefacts where Maven has troubles with this. Although I have
to date only created one artefact, the Ant build generates two. This
raises difficulties for Maven as it stands just now.

Post by Adam Sampson

Post by Russel Winder
Currently I am publishing Subversion HEAD to the Maven snapshot
repository as "org.codehaus.jcsp:jcsp:1.1-rc5-SNAPSHOT" pending any
publishing decision. Should I also publish the 1.1-rc4 release to the
main Maven repository?

I think publishing both versions would be a good idea, assuming it's not
too much additional work; as I understand it, some of the documentation
and examples in the trunk haven't yet been updated to match the most
recent API changes, so users may have good reasons for sticking with
the last release for now.

I have built and pushed an artefact jcsp-1.1-rc4-SNAPSHOT to the
snapshots repository (the URL is
http://snapshots.repository.codehaus.org/org/codehaus/jcsp/jcsp/1.1-rc4-SNAPSHOT/jcsp-1.1-rc4-20100216.161601-2.jar, the file has a weird name as I forgot to turn off uniqueness before uploading it), by checking out the 1.1-rc4 tag and building from that. If someone could check to see if this is a valid representation of 1.1-rc4 then if it is I can redo the push but this time to the main Maven repository. This jar will then be available via Maven in perpetuity.

Thanks.

PS I am using jcsp-1.1-rc5-SNAPSHOT from the Maven snapshots repository
and it seems to be working fine. Certainly well enough for demos next
week :-)

[Rick Beton]

<snipped>
I believe that Gradle or Maven would be better than Ant as the
build/project management tool for JCSP, but there may be a reason for
using Ant that I am not aware of.
Normally I would prefer Gradle over Maven, but in this case it was
quicker to use Maven. ...
Although Gradle is a bit less mature than Maven it is still usable for
production work. It's big advantage for JCSP is that it handles
multiple artefacts where Maven has troubles with this. ...

Sounds like you've justified using Gradle instead - does that mean you're
happy to re-do it? :)

...

Post by Adam Sampson
I think publishing both versions would be a good idea, assuming it's not
too much additional work; as I understand it, some of the documentation
and examples in the trunk haven't yet been updated to match the most
recent API changes, so users may have good reasons for sticking with
the last release for now.

Well, the trunk has moved on a l o n g way from 1.1rc4. In fact the
long-awaited generics are in there.

I'd like the opportunity to review where it's now at and offer some comments
on specific details; so far I've just been using the anonymous access to SVN
but if someone could give me access to Trac that might make it easier for me
to contribute.

Thanks,
Rick