[sword-devel] New public git mirror of Sword SVN trunk and why
greg.hellings at gmail.com
Mon Dec 17 17:10:28 MST 2012
On Mon, Dec 17, 2012 at 4:48 PM, Troy A. Griffitts <scribe at crosswire.org> wrote:
> Hi Jaak. Of course I would discourage confusing potential developers with
> an unofficial fork of the SWORD library on gitorious.
I have been maintaining a personal SWORD repository on github for
quite some time now (github.com/greg-hellings/Sword). It hasn't seemed
to cause any confusion, but I make sure that <master> is always
identical to SWORD's official Subversion <trunk> branch. I mainly use
it to shuttle my own branches and changes around from environment to
environment and to share them with others before I make a patch
against <master> for submission.
> But I'm confused by your comments.
> My apologies if I have any outstanding commits in my queue from you which I
> haven't committed. Do I?
I don't know about ones from Jaak, but I haven't seen a reply from you
about my SFTP patch submission (maybe I missed it?). It was a direct
feature request from a user in #xiphos and I already have a patch
prepared for Xiphos to support it. Our friends at Wycliffe are also
very excited about it because they are unable to expose FTP and HTTP
is a pain on their end and not well supported - but they are already
prepared with SSH/SFTP access for their target users.
> My complaint against the Bibletime code is that they inefficiently use the
> SWORD engine by trying to wrap everything in their own classes which even I
> have trouble understanding the intent. SWORD was made to be used in a
> frontend, and we make it pretty easy to use. I use it directly in the
> frontends and projects I have written and cater it to real frontend needs.
> Bibletime, for the long life of the project, has said they want to maintain
> this wrapper layer around SWORD such that they can replace SWORD with an
> alternate backend in the future. This has never happened, and I the
> Bibletime frontend code which has been 'protected' from SWORD has itself
> been rewritten many times, as far as I can see from the mailing list. And
> though we've tried to encourage collaboration for years, we have seen next
> to zero contributions to SWORD from any of the Bibletime team (no offence to
> Greg and others who contribute to many projects and who do contribute to
> SWORD). I have tried to get participation, but I usually only get
> complaints and arrogant calls for a complete rewrite from developers who
> don't even understand what's under the hood.
Perhaps a little background, which I present as objectively as I can:
One of the main complaints that's been going through IRC the past 3-6
months has been lack of a new release of the engine. Back in the
Spring we were gearing up for what was already a seemingly over-due
release. If my memory serves, you had said we would do a beta sometime
in April or May with the intention of releasing by June 1. You then
had a personal emergency that caused a delay in that time schedule,
but nothing has ever come since then - no comment, no response to a
timeline for a new release. I'm not sure if anyone else has been
christened as being allowed to cut alpha/beta/rc/final releases of the
engine, but if so they didn't step up to fill the gap.
Today's most recent bug that Jaak found in the engine is an
incompatibility with llvm+clang that causes compile failure in that
realm. This could pose an issue going forward as Apple has switched to
llvm+clang for its default compiler in Snow Leopard and I believe BSD
is going that direction as well. Turns out his bug is already fixed in
Sword's SVN (I'm guessing from gcc 4.7 patches?) but BibleTime can
only reliably track released versions for the sake of packaging
The discussion of the above bug, along with existing updates that are
in SWORD SVN (XHTML, HTTPS, deprecated API functions) but which are
not released led to some discussion in IRC about how to get reliable
releases out. Suggestions of bundling SWORD SVN in the application
were mentioned (but Linux packagers will absolute forbid that); once
again the suggestion of making BibleTime not rely on SWORD was
mentioned (a significant amount of effort would be required, but it
would be possible); also entertained was forking the project and
maintaining a separate project that would have no changes to the code
but would just make predictable releases of the engine (but that would
mean yet another thing for distros to package and for client build
systems to search for as a replacement to SWORD - thus representing a
huge barrier to such a fork doing any good).
But at this point BibleTime has apparently fielded at least one issue
related to building against SWORD's headers in a clang environment and
Xiphos is committed to using the XHTML filters. Both projects are,
therefore, desperate for a new release of the engine and some
developers are starting to wonder aloud if forking SWORD is the only
way that we'll ever see that. Even if the fork never diverges from the
base in terms of code content.
> I personally am old school and haven't acclimated to git. I've used it for
> work projects and can get around. There are many things I don't like, but
> git proponents seem to love it. I firmly don't believe that our source
> control system is the hindrance to contribution. We have a fairly high bar
> for contribution because so many projects use our engine. In my experience,
> most open source developers don't take code criticism well and are not
> willing to submit to an authority when they are volunteering their time--
> which is their prerogative. We don't allow our code to simply 'churn'
> because people want change it. We require a real use case and defence for
> changes, to protect our frontend developers from having to change their
> code, and our interface has remained fairly stable over the year because of
> 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.
> But unless this is your specific complaint, I'm not quite sure why the
> rebellious nature of your email, instead of a friendly conversation about
> how to get your developed new feature into the engine. I'd be happy to work
> with you on anything you've developed.
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. Locating SWORD's subversion repository has been a question
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, (2) no official presence on github and
(3) that the current source fails to build in a modern gcc environment
(meaning specifically 4.7). Each of these complaints I've seen more
than once, though I haven't bothered to remember if one person may
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.
Much of the smoldering stems primarily from the fact that it has been
26 months since a release. Even if we're not accepting major changes
and lots of code churn, we have enough commits on a regular basis to
warrant a regular release. My commit logs show 74 commits in 2012 and
81 commits in 2011 along with 7 in 2010 made after the last release of
the engine. That means those of us happy enough to run SWORD SVN in
our production world are sitting about 160 commits in front of the
public. Sure there's more than even the three or so issues I mentioned
above that are contained in those commits. Just from my own work I
know there are bugs in CMake, a reworking of how the SWIG bindings are
built, HTTPS, and improved detection of CLucene and ICU that I have
committed since October 22 of 2010. Even if we only were strict and
said we released every year on January 1 or something arbitrary like
that, we would at least have a strict pattern to adhere to. And we'd
only be half as far ahead of the public as we are now.
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
Just throwing my $2 in, like I always do.
> Just a generic defence,
> On 12/17/2012 01:13 PM, Jaak Ristioja wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> The Mirror
>> I created a new git mirror of the SVN trunk of Sword at gitorious:
>> Gitorious web page:
>> Git URLs:
>> git at gitorious.org:sword-svn-mirrors/trunk.git
>> In short: there's a possibility that there might arise forks.
>> The BibleTime team has long been contemplating on how to relate to
>> various issues with Sword and its development, which has somewhat
>> hindered the development of BibleTime, fixing or working around bugs
>> dependant on Sword etc. Up to this point, we have discussed
>> 1) writing an alternative backend for BibleTime to replace Sword,
>> 2) writing a better wrapper around Sword which would hide its
>> 3) a combination of 1) and 2) and allow BibleTime to use multiple
>> 4) forking Sword as a separate project, and
>> 5) embedding a forked version of Sword SVN in the source code of
>> BibleTime which would be partly kept up-to-date with the original project.
>> At this moment we have not yet reached any decision whatsover, but
>> these discussions have become rather frequent.
>> Personally, as a developer and the current lead of the BibleTime
>> project, I'm not satisfied with the code quality of Sword, and find
>> lacking the documentation of Sword interfaces and file formats. In
>> addition, as an outsider I have long found it difficult to do anything
>> about it, partly because of the centralized version control system
>> used by Sword (SVN), and partly because the lack of explicit
>> guidelines for new developers (how do I start, get my proposed fixes
>> and changes applied etc).
>> I just wanted to clarify what has been under discussion @ BibleTime
>> during the previous years and what we feel we're experiencing towards
>> using Sword. I'm not offering any silver bullets, except that for one
>> thing I urge the Sword project to release a new version of Sword soon.
>> However, personally, I'd place my bets on recruiting new developers
>> for the Sword library (and git).
>> Blessings (and please don't ban me :),
>> Jaak Ristioja
>> The BibleTime team
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.19 (GNU/Linux)
>> -----END PGP SIGNATURE-----
>> sword-devel mailing list: sword-devel at crosswire.org
>> Instructions to unsubscribe/change your settings at above page
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel