[sword-devel] New public git mirror of Sword SVN trunk and why
jaak at ristioja.ee
Tue Dec 18 01:03:17 MST 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 18.12.2012 00:48, Troy A. Griffitts wrote:
> Hi Jaak. Of course I would discourage confusing potential
> developers with an unofficial fork of the SWORD library on
I agree that this would cause confusion. It were better to avoid.
That's why I started this outrageous thread. :)
> 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?
Not that I'm aware of. However, I've seen several important issues on
sword-devel mailing list, one or two of which I've filed, end up being
discussed but never leading to actual solutions.
> 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.
As developers of a front-end, we are keen to have new features added.
We're displaying the module texts as HTML. But not just as Sword
passes them to us, but we would like something more. We want to
transform those Sword outputs, e.g. add some interactive features etc
etc. This requires some sort of additional processing. Developing such
processing is complicated, because we're not absolutely sure about the
format of the output Sword produces. Sometimes it has not been valid
and we've seen strange markup being output to the user which he or she
should not see. Working around such things has been a pain. Sword
lacking a full formal specialization (e.g. BNF grammar) of the output
in its documentation is a problem for us.
Of course I don't understand what's under the hood. I've been studying
the code and any documentation I've found, but still haven't figured
> 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 this.
Sword could apply a workflow which would not 'churn' the code, e.g.
with gatekeepers who optionally merge changes from others repository
clones to the main repository. See
> 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.
First of all, being rebellious is not my intent. I just want to push
the project for some good synergy. In reply to my first post I have
already received personal emails with requests to actually start
handling a fork, do a release from it ASAP, fix the interfaces and
compiler warnings. I don't want to fork. I don't think others want to
split the project either. But we need fixes to applied faster, bugfix
releases to be made earlier etc. Me and other volunteers are willing
to do some work for this. We're asking for Sword to meet us halfway.
I work as a C/C++ engineer, I have a MSc in Computer Science,
specializing in programming language theory. At work, I refactor a lot
of code, I read the ANSI C and C++03/C++11 standards (drafts) almost
daily. I'd like to extensively refactor and optimize your code. Are
you sure Sword could handle my stream of patches by email?
1) Anyway, what is the process of submitting patches? Only by email? git?
2) What is the process of reviewing and merging patches?
3) Who does all that?
4) How do I monitor this process?
5) What are my options to interact and accelerate development?
Maybe I've missed some documentation, but generally I feel that these
are unanswered questions. This is one obstacle. How does one contribute?
I'm not blaming anyone. I feel but strong gratitude for all you have
done for Sword and the community. However not all things are perfect
and well, I'm just pointing where it hurts. As for other living
organisms, pain is a sign of things not being ok. We can try to ignore
the pain and slowly fade to oblivion, we can get really depressed and
groan and moan and die, or we can try to be constructive and work to
eliminate the threats and ensure a better future.
I currently feel that our current progress has all three of the
aforementioned. We still somewhat ignore the problem, we still get
depressed, groan and moan, and we're just getting to become
constructive. As for getting constructive, there are obstacles. These
MUST be eliminated. For one, I think Sword should clarify and simplify
the contribution process to allow new developers, even random
passers-by to help out. Other obstacles are also being discussed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the sword-devel