[sword-devel] New public git mirror of Sword SVN trunk and why
mcepl at redhat.com
Tue Dec 18 06:28:18 MST 2012
On 18/12/12 01:10, Greg Hellings wrote:
> Sword's SVN (I'm guessing from gcc 4.7 patches?) but BibleTime can
> only reliably track released versions for the sake of packaging
Are you sure about this? There are many many packages in Fedora (and I
believe Debian will be in the same situation) which are from unreleased
VCS checkout. Not that it would matter for whole discussion, but just
suggesting workaround for your actual situation.
> were mentioned (but Linux packagers will absolute forbid that); once
That's just plainly not true if that should read "all Linux packagers"
... see for example
(I don't know Debian policy enough anymore, so I cannot point you to the
URL). The world is just not so neat anymore, so large distribution
couldn't survive insisting on having only releases with nice tags.
Yes, many packagers (me included) hugely prefer having released
tarballs, but it does not mean there is no way at all.
Also, yes, it is hugely preferable to have as few as possible patches in
the distribution packages, but it is not like the end of the world if
there are some. Especially patch which resolves FTBFS on the particular
platform is quite common.
All that saying, yes, where is the list of blockers of the new release?
>> Having said this, I do have a couple submissions (e.g., inter-versification
>> mapping framework) which I have not been diligent to confirm and commit.
Couldn't they just wait for the next release, if it was the way how to
avoid a fork?
> Although you seem happy to work with SVN, many (I do not say 'most'
> because I don't know any hard statistics) open source developers no
> longer are.
I would call a BS here. If they don't know how to use git svn, they
should read its manpage (or google for HOWTOs; and that's from me, who
uses git exclusively for all my projects, even though I have to use some
And of course, what stops anybody from creating and maintaining
https://github.com/crosswire/sword as the official GIT mirror and the
environment where the next release could be finished? Yes, that would be
fork, but a friendly fork expecting to be merged back to the main
repository (or starting to be a new repository).
And there is always my https://gitorious.org/sword/sword (synced with
SVN more or less daily, when the updating doesn't fail and I have
running computer during the day). I am ready to accept pull requests and
maintain the next branch which would be eventually merged into
mainstream repository (whatever it will be, SVN or git).
If anybody doesn't know how to use git, I am willing to help in
answering any questions (after your read http://www.progit.org/) here or
on IRC/XMPP. We went through it with JSword and they seem to be humming
pretty happily now.
> I've seen multiple times on IRC along with more than one question of
> whether the project is still active at all, citing as specific reasons
> (1) no new releases in a long time - it has been two years and two
> months since the last release,
This is the problem ... release early, release often.
> (2) no official presence on github
There was free software before github and the main advantage of git is
that one is not dependent on any central repository.
> have come in multiple times to ask about one of them. There are also
> occasional requests for modern translations, among them the NASB,
> which no action has been seen on.
The problem of NASB is not that it is modern, AFAIK, but that it is
commercial and they don't allow free distribution. What can we do about
that? Meanwhile we have ESV, which is very close to NASB in its target
audience and it is considered very good translation in the same rank of
quality as the best of them. Much bigger problem IMHO is that we don’t
have a good equivalent of NIV (general mainstream Bible for everybody)
and NLT for beginners. But there isn't much we can do about it, I am
afraid aside from prayers.
> Yes, there are people who will always want to fork and do things their
> way - if, some day, someone gets up the energy and time to do that,
> there's nothing to stop them from scratching that itch. But I think
> you'd see the majority of the current complaint go away with a release
> schedule that is established and adhered to. Even if it's a long cycle
> and not the 6-month cycle of Fedora and Ubuntu, if we knew that a
> release was coming and when it was, then both BibleTime and Xiphos
> could see updates and know when a feature - like XHTML - would be
There is nothing wrong with even shorter release cycles than six months
... release early, release often, release whenever there is something to
be released, and maintain your trunk/master so that it can be released
anytime. Just saying....
Blessings and Merry Christmas,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 251 bytes
Desc: OpenPGP digital signature
More information about the sword-devel