[sword-devel] Bibles in Beta

Peter von Kaehne refdoc at gmx.net
Mon Jun 16 14:07:30 MST 2008

DM Smith wrote:
>> Peter wrote: 
>> a) having a raw text repository where the texts are kept in some import
>> format (OSIS, ThML, whatever) under version control
> I think this needs to be the original text as we received it. Not the 
> import format. We should keep complete records of when, where, why and 
> how we got the text. Because the "place" where we got it might change 
> (the source is updated, or no longer available, ....), I don't think 
> that merely noting where it was obtained is sufficient.

Indeed. But by having version control it will always be possible to have
a look at the original source.

My thought is that RAW works simply as a subversion etc repository which
initially receives the text in whatever format we received it. and then
parallel to that the raw OSIS or whatever.

I found while working on my modules - which I all get in USFM is that i
need to work both on the USFm source to clean it up and then on the OSIS
text afterwards. So, both needs to be versioned. but that is a simple
"svn add" if svn is what we use.

> If I had the original text, I may have been able to compare the 
> resulting modules in beta for whether the "missing" verses were missing 
> in the source.


> Along with this should be the script(s) used to create the import format 
> to our mod creation tools, along with sufficient instruction for anyone 
> (with permission) to be able to repeat the transformation.


> I've suggested a repository of source in the past, but Troy was 
> reluctant/against such a thing. IIRC, his desire was that we did not 
> become a secondary source for texts, and that modules as an opaque 
> representation would be the only publication of texts by CrossWire 
> (excepting "original" work such as the KJV). (Troy, if I mis-represented 
> you, please speak up:) I don't know if having it under lock and key, 
> with a select group having keys, would satisfy his concerns.

I think this is correctly remembered - and Troy is correct in his desire
not to bypass and "improve" upon original sources, but at the smae time
we need to come out of our impasse and make the best of being a growing
group of disparate volunteers with diverging interests - mine e.g. are
simple, rough and ready Middle Eastern Bibles as tools for
evangelisation, others want scholarly tools. And Crosswire can easily
cater for all of this, but the mechanism for publication needs
broadening and smoothing

>> b) with named module owner(s) and contributor(s) -
>> c) with some form of automated build mechanism which could create the
>> modules in all the various formats we require (dmg, winzip, zip and raw)
> I think this is automated by the module download page. Were you thinking 
> of something more? (BTW, dmg is not possible without a Mac.)

TBH I actually do not know how it works. I do have beta write access,
but because of the DMG and the winzip I do not dare touching things. How
does it work? Who (or what script) produces the other formats?

>> d) have a discussion what constitutes "good enough" for a release and
>> what is good enough for a beta + implement two finished module
>> repositories - "public" and "beta" similar to now, but let the module
>> owners decide when they are "there"
> To me, good enough includes:
> Some level of transformational accuracy.
> Some level of completeness in the conf that goes beyond what is 
> minimally necessary for the module to work. This often is a user's first 
> impression of the module.

I think Good Enough (TM) is dependant on the repository

RAW needs simply a PD or otherwise allowed text which appears prima
facie suitable for Crosswire. I woudl expect that only inner core
contributors can create new modules and those can then give rights to
whomsoever they chose - including making someone else and new the owner

BETA needs a crosswire module which is good enough to get tested by
others + is content wise acceptable to the wider Crosswire community

MAIN needs a module which fulfils all that you said.


More information about the sword-devel mailing list