> -----Original Message-----
> From: Stefan G. Weichinger <[email protected]>
> So you suggest skipping my try to svn2git here? Does that mean that you will
> come up with new patches etc in github and plan to sync those over to the
> betsol/sourceforge-svn-repo?
[Chris Hassell]
Actually I am using the git-svn bridge and have pulled all of the subversion
branches/tags into place in a local copy of the SVN version. From there I act
upon indication of any new git commits to any branch ... compare on the correct
branch to add them and then apply them using the upstream 'git svn dcommit'
command.
However it is.. the flow is pretty small at this point, but both sides need to
remain identical. It's just a matter of allowing a normal 'Github' workflow to
help us out.
> Is ther ongoing work behind the scenes to deal with all the Issues and PRs on
> github already?
[Chris Hassell]
I've mentioned that to my boss. I, myself, am not a contributor on the github
side. We may be working with a skeleton crew to review and push through new
PRs (some for modernizing the build just recently) so one would hope we can
contact those few on Github and get some reviewing moving forward. Our branch
also has work for Unicode that has to be sent in as well.
Already we've seen one or two customer problems that were solved by upgrading
from 3.5 to get some modern versions of files, so there's good reason to
sharpen up the rest of the community version.
> I assume that as long the project looks that inactive it won't trigger any
> activity
> and contributions either.
[Chris Hassell]
Well, if any surprises are added on the subversion side it will be visible and
we can handle that case-by-case.
> Moving to the more modern and widely accepted platform of github should help
> maybe.
[Chris Hassell]
In my years of open source the only thing that truly kills off a project is the
success of a different approach ... and even then there needs to be a clear
path to migrate to it. Open source should not have to apologize for keeping a
project working and alive. Those who need it create its very lifeblood, and
that's a far better way to implement standards/infrastructure tools that can be
trusted for LTS.
> greets, Stefan
