[bt-devel] BibleTime's Goals (was Re: New passage selector proposal)

[Greg Hellings]

On Fri, Apr 20, 2012 at 3:23 PM, Troy A. Griffitts <scribe at crosswire.org> wrote:
>
>
> Greg Hellings <greg.hellings at gmail.com> wrote:
>
> Ok Greg, if you speak loudest for the Bibletime team, then I will answer your objections.
>
> So if I understand you correctly, the Bibletime team doesn't contribute because they cannot introduce dependencies into the core engine?
>

That is one influencing factor.

<snip>
> What is the argument? You actually want dependencies? This effort, and the effort to use if available, but not depend on: ICU, cURL, CLucene, zlib, libregex is for your benefit and simply good design and development for a library.
>

As I said, I understand your reasoning. It is a good design - but it
is not the only good design. Look at the dependency lists that
libraries like GTK+ have. Glib, ATK, cairo, gdk_pixbuf, jpeg, png,
expat, zlib, the list goes on. Some of those are optional others are
not. This does not mean that GTK+ is badly designed, it was a
conscious choice those developers made. And it's the same one I make
when I undertake work. If a library exists to do what I want, I will
use that library I won't write my own. It makes my code more
understandable to me and doesn't tie me up in those details which
someone else has already worked out.

You can't just wave your hands at me and say I'm wrong. I'm not saying
SWORD is wrong or that SWORD has to be different. You asked why I and
some others are reluctant to work on the engine and I'm telling you
why - I'd rather work with SWORD than in or on it for this reason.
I'll go in it when I need to and feel able but those are the
exceptions rather than the rules.

>
>>2) A heavily centralized development model that goes through
>>essentially one gatekeeper, maybe two.
>
> It is important to not refactor not make casual changes to a library. There are many many projects which will be affected by the smallest changes.  We took great pains to introduce alternate versification into the engine, making it completely backward compatible with existing frontends for their current module base and as easy as possible to support the new av11n modules-- in many places also without code changes. This means tough decisions to push submissions off until they are proven. Bibletime and other frontends are the perfect proving ground for new engine features, but BT won't even use SVN to tell us how our new code is working for you. I don't apologize for being a strict gatekeeper. Again, this is for your benefit.
>
> "Release early. Release often." Is not the mantra for a stable engine, the dependency of many projects.
>

Again, I'm not saying this is wrong for SWORD. I'm simply telling you
why there is friction that impedes people working. Strict gatekeepers
are good, because they ensure stability and consistency. None of the
gatekeepers that BibleTime has are lax - I am one of the gatekeepers
but I only push changes I understand well and have ensured the
stability is. Jaak and Gary are the same way. Martin is a gatekeeper
but doesn't let much through because he isn't active in the project
much anymore and we all want a stable application much as you want a
stable library with SWORD.

As Jaak said in his message, though, being a strict gatekeeper is not
incompatible with lowering the friction. All of BibleTime developers
work with git or Bazaar and we have found it very useful, more than
one of Xiphos' developers use the same to manage their contributions.

I use git in my SWORD work to maintain multiple patchsets. One that
holds the Xiphos specific changes needed for Windows, others that
maintain work on CMake and on mod2osis. Many projects are moving
towards it now because it makes submission feel easier for both the
submitter and the gatekeeper when they both understand the process.
But this is not a necessity as bridges between git and SVN and bzr and
SVN already exist. But the ability to submit git branches rather than
patches would lower the friction from the BT side because it is
already a git framework. It doesn't mean you need to stop being a
strict gatekeeper and git push rights to everyone.

Again, not a demand or a requirement, but if you're looking for
suggestions to help us work together, this is one of them.

>>It's a conscious choice you've made with your
>>strategies that falls at odds with out BT's people want to work. But
>>not with what we want done, so we do it by building on SWORD rather
>>than building into SWORD.
>
> So, if these are the 2 major barriers, then I hope the primary BT code contributors can sympathise, or at least respect the decisions we've made.
>

I believe we all sympathize with, understand, and respect the work in
SWORD. It's just that we don't always agree with the choices, and
because we think differently that makes working together difficult.
But it is something that BibleTime wants to work through because we
feel there are shortcomings in SWORD that we would like to overcome.
If doing so can make all of our work better then we are happy to work
towards that.

I'm not saying SWORD needs to change, and certainly not in all the
mentioned ways. Please don't take these as an attack on SWORD. But you
are looking for ways to help get BibleTime developers participating
more these are the barriers. The fewer there are the easier the
community grows.

I also echo Jaak's sentiments that the internals of the API are
difficult to unravel sometimes. A delineation between "internal" and
"external" classes would help me. Even if that delineation is not
strictly enforced in code the way some libraries will do, if there was
a "sword/private" which held the helper classes separated from the
intended-for-public APIs, that might help.

--Greg