[sword-devel] modules upload etc - suggestion

[Troy A. Griffitts]

A quick note in regard to this thread.  As Chris has mentioned, we have 
wanted to do this for quite some time.  Work has been done toward 
developing a facility for people to maintain module sets.  Wycliffe and 
others have expressed a desire to maintain their own repositories of 
texts and we have been working to allow this.  I'll spare the details, 
as most have not yet been worked out, but this and many other community 
tools should go online soon (very relative term) at:

http://community.crosswire.org

You can already sign up for your login id, but not much else is testable 
yet.  If you have Java/JSP/AJAX expertise and would like to help, please 
be heard.

	-Troy.



peter wrote:
> DM Smith wrote:
>> 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.  
> 
> No, this is right. we don't, but I am looking/asking for a place where
> we can put modules which are not for public ocnsumption, not even for
> beta-testing, but for getting right. This could be from a plain text to
> a completed module in OSIS or ThML.
> 
>>> 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).
> 
> This is the problem. Making a module reasonable quality is not easy for
> everyone. For me it is horribly difficult work. I am no programmer and
> find that i have to learn at every single step I take - and others are
> in the same position. Not the core developers
>>> 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
> 
> which is easily said, but difficult to do. Once a module is in beta and
> without permissions to change, update and improve on it with teh
> received feedback, the process to get it right involves to many humans
> and too little computers. Having beta in svn and more people having svn
> write access to teh module - not so big a problem, given that it is
> easier to roll back - errors could be corre cted there and then and do
> not need to involve you or others of the core people.
> 
> 
>>> 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.
> 
> I would love to, but I find programming kind of hard. My level is still
> somewhere at the "hello World" level.
> 
>>>> 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.
> 
> True, but then there are also all sorts of middling problems - poor
> quality OSIS, actual corrections, poor transcription of the text etc.
> 
>>>> 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?
> 
> Thanks, no. Chris. I can not write 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.
> 
> FTP would be a way, but svn would be better as it would allow fixing
> there and then, instead of re-uploading or working on the server.
> 
>>> 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.
>>
> 
> That is fair enough
> 
>>>> 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.
> 
> Often our texts _are_ the original OSIS texts, if not the original e-text.
> 
>>>> 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.
> 
> Great.
> 
> I am probably a whinge bag and should simply grow up and learn proper
> computing :-)
> 
> Peter
> 
> 
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> 
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page