[sword-devel] modules upload etc - suggestion

[DM Smith]

On Jan 15, 2008, at 5:33 AM, Chris Little wrote:

> peter wrote:
>> One of the things which are recurrent on the mailing list is the
>> difficulty + slowness of getting a module through the door - i.e.  
>> both
>> to put it into beta and to get it from beta eventually transferred  
>> into
>> release.
>
> I don't know what you mean by 'alpha' since we have no such thing.  
> It's
> not particularly difficult to get a module into beta, provided it's of
> reasonable quality (well made, relevant, something we would ever
> release, etc.) and distributable (not copyrighted or licensed to us  
> for
> distribution).
>
> Getting from beta to release requires that the module have been tested
> for a while (and any reported errors be corrected, of course) and that
> its required Sword version be supported on at least the major  
> platforms
> (i.e. by BibleTime, GnomeSword, & BibleCS). We should probably include
> MacSword in this list, but I don't follow MacSword development
> sufficiently to know what it's supporting--maybe I'll go buy a MacBook
> Air tomorrow or finally start running MacOS on my mini.

MacSword is still not at 1.5.9. The KJV, ESV, and other 1.5.9 modules  
have problems in it.

 From what I can tell, development on it has stalled and work is now  
being done on a new application, Eloquence, which currently requires  
the latest version of MacOS, called Leopard. At this point an Install  
Manager is available.

I would like to suggest that MacSword be, at the very least, put into  
perpetual beta and recompiled with the latest stable version of the  
SWORD api.


> And I would like
> to include Bible Desktop, as well, but it might be a greater challenge
> since it's using completely different drivers that might develop at a
> different rate.

Please don't include BibleDesktop in any consideration as to whether a  
module should be moved from beta to production. But do feel free to  
use BibleDesktop and to test module with it. :)

Our filter architecture is based upon the spec for GBF, ThML,  
Plaintext and OSIS. Basically, we have two types of filters. One type  
that transforms to OSIS and another that transforms from that to HTML.  
It is fairly easy to modify these filters or to add another, like TEI.

Because of the length of time that modules spend in purgatory, er, I  
mean beta, I have plenty of time to test and make changes.

>
>
> At any rate, right now we can't release any of the 1.5.10-requiring
> module because BibleCS is still at 1.5.9. If you would like to see  
> them
> released, contribute to fixing the existing known BibleCS 1.5.10 bugs.
>
>> There is also no fast way of doing corrections on released module -  
>> at
>> least for those without adequate rights on the server. Another
>> difficulty for those of us behind slow upload connections are that  
>> even
>> minor changes in the module become a nightmare of hour long uploads.
>
> There are two kinds of errors in our modules: those that are our fault
> due to conversion mistakes and those that are in the upstream  
> providers'
> source documents. The former kind we will fix. The latter, we  
> generally
> won't, since we are really not set up to be a text maintainer and we
> don't have the expertise to be one.
>
>> Could I suggest the following reorganisation?
>>
>> 1) a reasonably wide open alpha area where plenty can upload - i.e.
>> everyone with some reasonably close connection to CrossWire. We can  
>> deal
>> with copyright problems there reactively - an assertion that a  
>> module is
>> OK should be enough if accompanied by
>
> I think we would like to do something like this. Are you  
> volunteering to
> write the code?

All it need to be is an area that can be FTP'd to, with some kind of  
easy to maintain whitelist. I think I can find code for it. But I  
don't know that I am volunteering.

>
>
> I do have a problem with dealing with copyright problems reactively,  
> but
> I think we could make a fairly simple process of submission ->  
> approval
> -> release.

My concern about copyright problems, is that I can envision people  
using the location to post a Portuguese module (seems all available PT  
text are copyrighted) or others. I don't think it should be wide open,  
but governed by a whitelist, with uploads being audited against that  
whitelist.

The upload should consist of the same that is asked for any module.  
Pedigree papers (how to get the source, age of the text,  
permissions, ....) , conf and text ready to run through a module  
conversion utility, such as osis2mod. In some cases, the module would  
suffice as a start.

I think the practice should be that every new module have its origin  
examined on sword-devel before it is put to alpha.


>
>
>> 2) a wider range of people who can upload from alpha to beta
>
> I don't see a problem with allowing anyone to post to alpha via an
> automatic submission process, provided an approval process is in  
> place.
>
> Speaking from experience, more people putting things in the existing
> beta site makes problems because of permissions problems. Although  
> quite
> a number of people have permission to put items in the beta  
> repository,
> I think it's probably best if one person (presently me) be in charge  
> of
> public submissions.
>
>> 3) both alpha and beta running under subversion - so that changes  
>> can be
>> made on the server and done in a collective fashion. Often there is  
>> one
>> who understands the language and the module, while another has much
>> better clue of the relevant technology.
>
> I'm guessing that this is supposed to remedy the issue of large
> downloads, but I don't see how it does so at all. It just complicates
> the whole process by making maintenance of the SVN repository itself  
> and
> dealing with all of the logins into a nightmare. In practice, I don't
> believe anyone other than the person in charge has modified the SVN
> repositories pertaining to the two modules in SVN.

I don't think SVN is appropriate unless we plan to maintain copies of  
the original e-texts.

>
>
>> 4) a module maintainer for each module who can authorise update
>> releases, so that these do not need to go through the current slow
>> approval process.
>
> See above, speed of approval not related to the modules themselves.
>
>> It took me several months to get FarsiOPV into beta, FarsiLB and  
>> FarsiTV
>> are still not in beta despite several requests and FarsiOPV needs  
>> some
>> urgent corrections to the configuration file.
>
> Send submissions to sword-modules at crosswire.org. Things not sent there
> will probably be ignored forever.
>
> There are modules that have been sent there that I haven't yet  
> released,
> but I should have everything currently sent there released in the next
> week or two (excluding things that we wouldn't release).

Looking forward to seeing them.