1:46 p.m.
As part of the rebranding that we'll be doing soon, we're going to switch version
control repositories from our current SVN location () to another repository. We can very
easily stay on the same SVN instance, or we can take the opportunity to switch to Git. Of
course, it isn't "now or never". Even though the rebranding point would be
an excellent time to switch (since we have to move repositories anyway), it isn't the
only time we could switch to Git. So if it's not now, I suspect we'll make the
switch within six months (or so).
I'd like to hear what people have to say on the matter.
Personally, I've been using Git locally for many months, and couldn't imagine
going back. I simply love the ability to have local branches (that are almost always
named for the JIRA issue) and to switch between them very easily. And I'm not even
benefiting from the ability to push these branches out anywhere else. The Git Eclipse
plugin works very well for me, but I'm very used to the command-line and don't
expect much from my Eclipse Team UI functionality anymore. (I really just want Eclipse to
tell me which files are changed locally, which the plugin does very well - everything else
I use the command line for because its far easier IMO.)
However, I do have several concerns. One of them is whether this raises or lowers the bar
for people downloading the source, submitting patches, or for becoming new committers.
For people that only have SVN experience, I think this will dramatically raise the bar
because Git will be a big unknown for them. On the other hand, Git is becoming extremely
popular and used on a lot of projects, so while this might be the norm now, I don't
expect it will be in a year. For people that do know Git, our using Git would actually
_lower_ the bar for their submitting patches, because they can create a patch on their own
Git repository (or if that's not accessible then on a site like GitHub) and give us a
URL, where we can pull it in to review and possibly commit.
Another concern is what the Git experience is on Windows, which I can't evaluate. The
Git experience is pretty much the same on OS X, Unix, and Linux mostly because
command-line support is so similar. But while Windows has very different command-line
support, it does seem that msysgit (http://code.google.com/p/msysgit/) gets around that
issue pretty well. I'd love to hear about your experience with Git on Windows,
though.
One concern I have had in the past was whether our Hudson continuous integration system
will support Git. I happy to say that a Git plugin for Hudson has been available for some
time, that our Hudson team have a test environment where they've install it, and I
will be creating some test jobs for them. So while this still is an issue, it
shouldn't be within a few weeks of the New Year (or sooner if I can find the time).
Please stand up and be heard.
Best regards,
Randall
3:37 p.m.
I vote to keep the SVN repository. SVN is the standard and most everyone is familiar with
it. The Eclipse SVN plugin is mature and generally works very well (though it would be
nice to be able to have a hierarchical root project). And, per Randall, Git has a nice way
of dealing with SVN for those who want to use Git with an SVN repository.
I personally avoid the command-line as much as possible. I much rather look at an Eclipse
View than a terminal window when trying to figure out things. I like an IDE to be an IDE
and Eclipse does a pretty good job.
I've gotten by without using local branches so far and don't think I will all of
sudden start using them just because we are made to use Git. So if that is the main reason
to switch I'm not buying it.
There is no need to rush the adoption of Git. As Randall says this can be done later if
the need becomes more justified. Let the Git tooling mature. Let other projects take the
credit for moving to Git first.
To be fair I don't know enough about the Git Eclipse plugin. Is it stable? Can it be
used just like the SVN plugin (i.e., check-in, check-out, diffs, create/delete projects,
etc)? If the answer is yes, I might be more open to it.
I don't see the compelling need to force everyone off the standard way (which is
pretty darn good).
My vote is keep SVN.
----- Original Message -----
From: "Randall Hauch" <rhauch(a)redhat.com>
To: "JBoss DNA" <dna-dev(a)lists.jboss.org>
Sent: Tuesday, December 8, 2009 1:46:35 PM GMT -06:00 US/Canada Central
Subject: [dna-dev] Version control poll
As part of the rebranding that we'll be doing soon, we're going to switch version
control repositories from our current SVN location () to another repository. We can very
easily stay on the same SVN instance, or we can take the opportunity to switch to Git. Of
course, it isn't "now or never". Even though the rebranding point would be
an excellent time to switch (since we have to move repositories anyway), it isn't the
only time we could switch to Git. So if it's not now, I suspect we'll make the
switch within six months (or so).
I'd like to hear what people have to say on the matter.
Personally, I've been using Git locally for many months, and couldn't imagine
going back. I simply love the ability to have local branches (that are almost always
named for the JIRA issue) and to switch between them very easily. And I'm not even
benefiting from the ability to push these branches out anywhere else. The Git Eclipse
plugin works very well for me, but I'm very used to the command-line and don't
expect much from my Eclipse Team UI functionality anymore. (I really just want Eclipse to
tell me which files are changed locally, which the plugin does very well - everything else
I use the command line for because its far easier IMO.)
However, I do have several concerns. One of them is whether this raises or lowers the bar
for people downloading the source, submitting patches, or for becoming new committers.
For people that only have SVN experience, I think this will dramatically raise the bar
because Git will be a big unknown for them. On the other hand, Git is becoming extremely
popular and used on a lot of projects, so while this might be the norm now, I don't
expect it will be in a year. For people that do know Git, our using Git would actually
_lower_ the bar for their submitting patches, because they can create a patch on their own
Git repository (or if that's not accessible then on a site like GitHub) and give us a
URL, where we can pull it in to review and possibly commit.
Another concern is what the Git experience is on Windows, which I can't evaluate. The
Git experience is pretty much the same on OS X, Unix, and Linux mostly because
command-line support is so similar. But while Windows has very different command-line
support, it does seem that msysgit (http://code.google.com/p/msysgit/) gets around that
issue pretty well. I'd love to hear about your experience with Git on Windows,
though.
One concern I have had in the past was whether our Hudson continuous integration system
will support Git. I happy to say that a Git plugin for Hudson has been available for some
time, that our Hudson team have a test environment where they've install it, and I
will be creating some test jobs for them. So while this still is an issue, it
shouldn't be within a few weeks of the New Year (or sooner if I can find the time).
Please stand up and be heard.
Best regards,
Randall
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
4:23 p.m.
On Dec 8, 2009, at 3:37 PM, Daniel Florian wrote:
I've gotten by without using local branches so far and don't
think I will all of sudden start using them just because we are made to use Git. So if
that is the main reason to switch I'm not buying it.
To date, we've been very much on a "feature-boxed" release mode, where our
releases are determined primarily by the completion of major features. Each of our
releases has focused on one or several of the JCR 1.0 features, so the times between
releases has varied wildly. This has (sort of) worked to date, but need to move to a
"time-boxed" release schedule that is more inline with JBoss Community best
practices and more conducive to open-source projects. And because 0.7 and 1.0 will have
all of the critical JCR features (except versioning, which is optional and also coming
soon), we will be moving to "time-boxed" releases with 1.1.
"Time-boxed" releases mean that our releases will be on a fairly regular
schedule, and will include all of the features/fixes made up to that point. This means
that if a feature is not ready, it will not be included in the release. And rather than
remove incomplete features, we will instead be developing all features (and potentially
all issues) on separate branches, and merging those changes onto the mainline release
branch (and other branches) as deemed appropriate.
Working with multiple branches in Git is trivial and light-weight. I can easily merge
multiple branches onto my branch (e.g., pull in some fixes that people have committed on
other issue branches), and yet merging my branch onto the mainline branch is again very
easy even whether or not the branches I pulled in were already merged. Git does all the
bookkeeping for me.
Now, frankly, SVN merging scares the crap out of me because it's a PITA and very
error-prone. JBoss.org is currently running version 1.4.2, which does not have support
for "easier" merging, and we'd have to rely upon svnmerge.py[1] or something
similar. Plus, even with the "easier" merging abilities of SVN 1.5, it still is
difficult to merge a set of changes onto multiple branches (which may be required). Dan,
you worked with SVN branches when working on the Eclipse plug-in - can you imagine doing
that for every issue and feature? And what worries me even more is that we'd relax
our dev policies and practices because of difficulties and limitations of a tool like SVN,
when there are other far-superior tools readily available.
So please bear this in mind.
Best regards,
Randall
[1] http://www.orcaware.com/svn/wiki/Svnmerge.py
4:43 p.m.
So what kind of Eclipse tooling if available for git, if any? I think the main thing I
care about using Eclipse for over the command line regarding the repository is the
comparison editors. Is there such an animal for git?
On Dec 8, 2009, at 4:23 PM, Randall Hauch wrote:
On Dec 8, 2009, at 3:37 PM, Daniel Florian wrote:
> I've gotten by without using local branches so far and don't think I will all
of sudden start using them just because we are made to use Git. So if that is the main
reason to switch I'm not buying it.
To date, we've been very much on a "feature-boxed" release mode, where our
releases are determined primarily by the completion of major features. Each of our
releases has focused on one or several of the JCR 1.0 features, so the times between
releases has varied wildly. This has (sort of) worked to date, but need to move to a
"time-boxed" release schedule that is more inline with JBoss Community best
practices and more conducive to open-source projects. And because 0.7 and 1.0 will have
all of the critical JCR features (except versioning, which is optional and also coming
soon), we will be moving to "time-boxed" releases with 1.1.
"Time-boxed" releases mean that our releases will be on a fairly regular
schedule, and will include all of the features/fixes made up to that point. This means
that if a feature is not ready, it will not be included in the release. And rather than
remove incomplete features, we will instead be developing all features (and potentially
all issues) on separate branches, and merging those changes onto the mainline release
branch (and other branches) as deemed appropriate.
Working with multiple branches in Git is trivial and light-weight. I can easily merge
multiple branches onto my branch (e.g., pull in some fixes that people have committed on
other issue branches), and yet merging my branch onto the mainline branch is again very
easy even whether or not the branches I pulled in were already merged. Git does all the
bookkeeping for me.
Now, frankly, SVN merging scares the crap out of me because it's a PITA and very
error-prone. JBoss.org is currently running version 1.4.2, which does not have support
for "easier" merging, and we'd have to rely upon svnmerge.py[1] or something
similar. Plus, even with the "easier" merging abilities of SVN 1.5, it still is
difficult to merge a set of changes onto multiple branches (which may be required). Dan,
you worked with SVN branches when working on the Eclipse plug-in - can you imagine doing
that for every issue and feature? And what worries me even more is that we'd relax
our dev policies and practices because of difficulties and limitations of a tool like SVN,
when there are other far-superior tools readily available.
So please bear this in mind.
Best regards,
Randall
[1] http://www.orcaware.com/svn/wiki/Svnmerge.py
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
Thanks,
JPAV
5:36 p.m.
I just installed the latest (0.6.xx.....) integration build of the Eclipse plugin, and
they've added a ton of stuff. Check out the user guide [1], which has screenshots and
instructions. You can now:
select a project, folder, package, or file and get the history (which includes a visual
history), see all the information about any of the commits, and even do a diff between
different commits or between a commit and my local workspace.
commit within Eclipse (this was a bit wonky on 0.4.0, but is nice and clean now). In fact,
you can even click a checkbox and your commit will ammend a previous commit [3]
create branches (this dialogs is a bit sparse compared with the images on the site,
probably because I'm using Git locally with a remote SVN repository, and all my
branches are off of the 'master' branch, which is important for the Git-SVN
integration)
see what changes you've made (what's been staged already); see [4]
quick-diff support to show in your editor which lines are changed in your local workspace
(relative to the base commit); see [5]
Some of the dialogs don't show quite as much using my local Git as they do in some of
the screenshots. I suspect this is entirely because I'm using Git locally with a
remote SVN repository, and all my branches are based off of the 'master' branch,
which is important for the Git-SVN integration.
Here are some limitations I see:
can't create a patch. This shouldn't be an issue, because you need to do this
from the command line, as Eclipse won't create a single top-level patch per our
Reference Guide. But we actually won't need patches, because if all feature/issue work
is done on their own branches, the branches themselves have the necessary history and
changes (as long as the branch is pushed to a common Git or accessible by those that need
it).
I haven't found a way to merge branches
there's no Team Synchronization view. I think this isn't a natural way to think
about pulling changes with Git anyway, since with Git things stay on their branches and
you end up comparing or diffing branches (which is possible). I think this is a case of
"there's a better way to do this with Git".
Overall, I find it extremely useful.
Best regards,
Randall
[1] http://wiki.eclipse.org/EGit/User_Guide
[2] http://www.eclipse.org/egit/
[3] http://wiki.eclipse.org/EGit/User_Guide/Commit#Ammending_Commits
[4] http://wiki.eclipse.org/EGit/User_Guide/State#Comparing_Content
[5] http://wiki.eclipse.org/EGit/User_Guide/State#Quickdiff
On Dec 8, 2009, at 4:43 PM, John Verhaeg wrote:
So what kind of Eclipse tooling if available for git, if any? I
think the main thing I care about using Eclipse for over the command line regarding the
repository is the comparison editors. Is there such an animal for git?
On Dec 8, 2009, at 4:23 PM, Randall Hauch wrote:
> On Dec 8, 2009, at 3:37 PM, Daniel Florian wrote:
>
>> I've gotten by without using local branches so far and don't think I will
all of sudden start using them just because we are made to use Git. So if that is the main
reason to switch I'm not buying it.
>
> To date, we've been very much on a "feature-boxed" release mode, where
our releases are determined primarily by the completion of major features. Each of our
releases has focused on one or several of the JCR 1.0 features, so the times between
releases has varied wildly. This has (sort of) worked to date, but need to move to a
"time-boxed" release schedule that is more inline with JBoss Community best
practices and more conducive to open-source projects. And because 0.7 and 1.0 will have
all of the critical JCR features (except versioning, which is optional and also coming
soon), we will be moving to "time-boxed" releases with 1.1.
>
> "Time-boxed" releases mean that our releases will be on a fairly regular
schedule, and will include all of the features/fixes made up to that point. This means
that if a feature is not ready, it will not be included in the release. And rather than
remove incomplete features, we will instead be developing all features (and potentially
all issues) on separate branches, and merging those changes onto the mainline release
branch (and other branches) as deemed appropriate.
>
> Working with multiple branches in Git is trivial and light-weight. I can easily merge
multiple branches onto my branch (e.g., pull in some fixes that people have committed on
other issue branches), and yet merging my branch onto the mainline branch is again very
easy even whether or not the branches I pulled in were already merged. Git does all the
bookkeeping for me.
>
> Now, frankly, SVN merging scares the crap out of me because it's a PITA and very
error-prone. JBoss.org is currently running version 1.4.2, which does not have support
for "easier" merging, and we'd have to rely upon svnmerge.py[1] or something
similar. Plus, even with the "easier" merging abilities of SVN 1.5, it still is
difficult to merge a set of changes onto multiple branches (which may be required). Dan,
you worked with SVN branches when working on the Eclipse plug-in - can you imagine doing
that for every issue and feature? And what worries me even more is that we'd relax
our dev policies and practices because of difficulties and limitations of a tool like SVN,
when there are other far-superior tools readily available.
>
> So please bear this in mind.
>
> Best regards,
>
> Randall
>
> [1] http://www.orcaware.com/svn/wiki/Svnmerge.py
> _______________________________________________
> dna-dev mailing list
> dna-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/dna-dev
Thanks,
JPAV
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
7:03 a.m.
Comments inline.
-----Original Message-----
From: dna-dev-bounces(a)lists.jboss.org [mailto:dna-dev-
bounces(a)lists.jboss.org] On Behalf Of Randall Hauch
Sent: Tuesday, December 08, 2009 2:47 PM
To: JBoss DNA
Subject: [dna-dev] Version control poll
Personally, I've been using Git locally for many months, and couldn't
imagine going back. I simply love the ability to have local branches
(that are almost always named for the JIRA issue) and to switch between
them very easily. And I'm not even benefiting from the ability to push
these branches out anywhere else. The Git Eclipse plugin works very well
for me, but I'm very used to the command-line and don't expect much from
my Eclipse Team UI functionality anymore. (I really just want Eclipse to
tell me which files are changed locally, which the plugin does very well -
everything else I use the command line for because its far easier IMO.)
There were several times this year when I was working on multiple issues simultaneously
(or had completed 1-2 issues pending review and had started on another). I ended up
having to create patches and revert as I shifted between issues or only work on issues
that affected completely different sets of files (e.g., one connector-layer issue and one
JCR-layer issue) and remember which was which.
I broke the build many times because I fouled up this process.
In theory, Git would make this much easier, right?
However, I do have several concerns. One of them is whether this
raises
or lowers the bar for people downloading the source, submitting patches,
or for becoming new committers.
I think it will. Had this project been git-only a year ago, I probably never would have
gotten involved. It's not that git is bad or that learning git is hard, it's just
one more bit of inertia to overcome.
For people that only have SVN experience,
I think this will dramatically raise the bar because Git will be a big
unknown for them. On the other hand, Git is becoming extremely popular
and used on a lot of projects, so while this might be the norm now, I
don't expect it will be in a year.
Then, IMHO, we should move to Git in a year and let other projects train people, develop
best practices, and support tooling improvements. IMHO, I think we should be focused on
advancing the state-of-the-art in federating data sources, not in build processes.
For people that do know Git, our using
Git would actually _lower_ the bar for their submitting patches, because
they can create a patch on their own Git repository (or if that's not
accessible then on a site like GitHub) and give us a URL, where we can
pull it in to review and possibly commit.
I think that the set of people who know Git, know Java, and might submit a DNA patch is a
very small one right now. I think the set of people who might build from trunk right now
(a prereq for creating a patch) but wouldn't bother if it meant they had to install
and learn Git is a larger set.
But that's right now. I wouldn't be shocked if things were different by this time
next year.
Another concern is what the Git experience is on Windows, which I
can't
evaluate. The Git experience is pretty much the same on OS X, Unix, and
Linux mostly because command-line support is so similar. But while
Windows has very different command-line support, it does seem that msysgit
(http://code.google.com/p/msysgit/) gets around that issue pretty well.
I'd love to hear about your experience with Git on Windows, though.
I'll try this out post-0.7 and let you know.
One concern I have had in the past was whether our Hudson continuous
integration system will support Git. I happy to say that a Git plugin for
Hudson has been available for some time, that our Hudson team have a test
environment where they've install it, and I will be creating some test
jobs for them. So while this still is an issue, it shouldn't be within a
few weeks of the New Year (or sooner if I can find the time).
Why would we want to be the guinea pig for this? :-)
9:04 a.m.
On Dec 9, 2009, at 7:03 AM, Brian Carothers wrote:
Comments inline.
> -----Original Message-----
> From: dna-dev-bounces(a)lists.jboss.org [mailto:dna-dev-
> bounces(a)lists.jboss.org] On Behalf Of Randall Hauch
> Sent: Tuesday, December 08, 2009 2:47 PM
> To: JBoss DNA
> Subject: [dna-dev] Version control poll
>
> Personally, I've been using Git locally for many months, and couldn't
> imagine going back. I simply love the ability to have local branches
> (that are almost always named for the JIRA issue) and to switch between
> them very easily. And I'm not even benefiting from the ability to push
> these branches out anywhere else. The Git Eclipse plugin works very well
> for me, but I'm very used to the command-line and don't expect much from
> my Eclipse Team UI functionality anymore. (I really just want Eclipse to
> tell me which files are changed locally, which the plugin does very well -
> everything else I use the command line for because its far easier IMO.)
There were several times this year when I was working on multiple issues simultaneously
(or had completed 1-2 issues pending review and had started on another). I ended up
having to create patches and revert as I shifted between issues or only work on issues
that affected completely different sets of files (e.g., one connector-layer issue and one
JCR-layer issue) and remember which was which.
I broke the build many times because I fouled up this process.
In theory, Git would make this much easier, right?
Every day (literally!) I switch branches to work on something else, without ever creating
a patch. (Git has the uber-handy 'stash', but that's only needed if
you're not ready to commit your changes locally.) Sometimes I do this multiple times.
Oh, and I get version control on all my branches, and Git does help merge changes between
different branches. So for example, if you fix an error on one branch (that hasn't
yet been pushed to trunk), you can pull that change (or all the changes on that branch)
into your branch with a simple merge.
Git-SVN provides this functionality locally. But that's a still nowhere near what
using Git all 'round will give you. Right now, if I needed a fix that you have
locally, I would need to get a patch (even if we were both using Git-SVN locally). If we
were using Git all 'round, we'd still push commits on our branches to a shared Git
(and merge them onto the 'trunk' branch (we'd probably use a branch name that
corresponded to the release effort), but I could very easily pull in some or all of your
changes in my branch. Easy-peasy.
> However, I do have several concerns. One of them is whether this raises
> or lowers the bar for people downloading the source, submitting patches,
> or for becoming new committers.
I think it will. Had this project been git-only a year ago, I probably never would have
gotten involved. It's not that git is bad or that learning git is hard, it's just
one more bit of inertia to overcome.
I'd probably agree with you. A year ago, Git didn't have nearly the uptake that
it does have now. Today, I think the "standard" for new projects is either Git
or Mercurial.
> For people that only have SVN experience,
> I think this will dramatically raise the bar because Git will be a big
> unknown for them. On the other hand, Git is becoming extremely popular
> and used on a lot of projects, so while this might be the norm now, I
> don't expect it will be in a year.
Then, IMHO, we should move to Git in a year and let other projects train people, develop
best practices, and support tooling improvements. IMHO, I think we should be focused on
advancing the state-of-the-art in federating data sources, not in build processes.
I don't want to switch to Git because it's cool or fun or state of the art. I
want to switch because Git-SVN already makes my life an order of magnitude easier (lots of
branch switching), and would be another order of magnitude if we went whole-hog Git. Yes,
all the committer's processes would change, because we'd be moving to doing all
work on branches, and the main release branch becomes nothing but a merge point.
...
> One concern I have had in the past was whether our Hudson
continuous
> integration system will support Git. I happy to say that a Git plugin for
> Hudson has been available for some time, that our Hudson team have a test
> environment where they've install it, and I will be creating some test
> jobs for them. So while this still is an issue, it shouldn't be within a
> few weeks of the New Year (or sooner if I can find the time).
Why would we want to be the guinea pig for this? :-)
Because it's not much work (provide a Git repository, define a Hudson job that works
like ours, and help them work out the kinks), and I'm oh-so-tired of SVN. :-)
2:39 p.m.
On Dec 9, 2009, at 9:04 AM, Randall Hauch wrote:
Git-SVN provides this functionality locally. But that's a still
nowhere near what using Git all 'round will give you. Right now, if I needed a fix
that you have locally, I would need to get a patch (even if we were both using Git-SVN
locally). If we were using Git all 'round, we'd still push commits on our
branches to a shared Git (and merge them onto the 'trunk' branch (we'd
probably use a branch name that corresponded to the release effort), but I could very
easily pull in some or all of your changes in my branch. Easy-peasy.
I don't want to switch to Git because it's cool or fun or
state of the art. I want to switch because Git-SVN already makes my life an order of
magnitude easier (lots of branch switching), and would be another order of magnitude if we
went whole-hog Git. Yes, all the committer's processes would change, because we'd
be moving to doing all work on branches, and the main release branch becomes nothing but a
merge point.
I've been having lots of version troubles with the Eclipse SVN connector not being
compatible with the command-line version on my machine, so my vote is to convert to git
now. Purely selfish reasons, but there it is.
Thanks,
JPAV
9:27 a.m.
For the time being, we have too many things on our plate to switch. I will likely bring
this up again in a few months, after we all get sick of SVN branches.
Thanks for the good discussion!
Best regards,
Randall
On Dec 10, 2009, at 2:39 PM, John Verhaeg wrote:
On Dec 9, 2009, at 9:04 AM, Randall Hauch wrote:
> Git-SVN provides this functionality locally. But that's a still nowhere near
what using Git all 'round will give you. Right now, if I needed a fix that you have
locally, I would need to get a patch (even if we were both using Git-SVN locally). If we
were using Git all 'round, we'd still push commits on our branches to a shared Git
(and merge them onto the 'trunk' branch (we'd probably use a branch name that
corresponded to the release effort), but I could very easily pull in some or all of your
changes in my branch. Easy-peasy.
> I don't want to switch to Git because it's cool or fun or state of the art.
I want to switch because Git-SVN already makes my life an order of magnitude easier (lots
of branch switching), and would be another order of magnitude if we went whole-hog Git.
Yes, all the committer's processes would change, because we'd be moving to doing
all work on branches, and the main release branch becomes nothing but a merge point.
I've been having lots of version troubles with the Eclipse SVN connector not being
compatible with the command-line version on my machine, so my vote is to convert to git
now. Purely selfish reasons, but there it is.
Thanks,
JPAV
5833
days inactive
5843
days old
8 comments
4 participants
participants (4)
-
Brian Carothers -
Daniel Florian -
John Verhaeg -
Randall Hauch