[sword-devel] Taming Wild Threads (was: Getting stuff done (Re: External links))

[Peter von Kaehne]

Chris Little wrote:
> I think these are Peter's descriptions. I'll try to divine their meaning 
> and give something a bit more clear.
> 
>> 	Any eternal loops or other structural problems? (What does this mean?)
> 
> I don't know why this is the label. It sounds like a reference to 
> problems which are technically impossible for users of the importers 
> (but could be created by very old importers).

"Structural" problems abounded at the time - partially these were module
content, partially they seemed to be module caused but were in reality
odd front end bugs triggered by non-standard modules (ie. e.g. only a
few disparate books of the Bible), As this has been teased out and
sorted we should rename the column - I just realise that Chris has
alreadyt done so - Thanks Chris.

>> 	Conf Problems? (Does this simply mean that the basics are there as 
>> defined on the wiki?)
> 
> This means that the basics are there. All necessary entries (e.g. option 
> filters) are present. No unnecessary entries are present (e.g. option 
> filters for features not present in the text). And that all information 
> that is present is correct.

Absent or superfluous options are both very common. Unclear copyright
status or licensing, poor description (e.g claiming something is a Bible
but is only a single testament etc),

> 
>> 	Ready for import into main repository? (Does this simply mean that all 
>> other categories are satisfied? What if some front-ends don't properly 
>> display the module?)

The idea of this column is to indicate the current conclusion of the
previous columns. Anytime the module is updated all columns should be
deleted. Any serious problems meriting discussion beyond a single
incarnation/update can go into a subpage under the name of the module.
To merit a "Ready" all previous cloumns should be problem free and the
module should display well on GS, BibleCS, SwordWeb and BD.

I am not a programmer and therefore often not able to state why a module
fails - many of the tests have exposed ultimately bugs which are not
related to the actual module at all, but to our import mechanism, to
front ends etc. It does not matter - simply test and write down your
findings. If you can divine out who/which programme in the process is
causing the problem alert the right person, otherwise, even just writing
it down as it appears is fine and will eventually trigger the next steps.

HTH

Peter