Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Michael Johnson]

Robert's point about also standardizing Scripture metadata with the 
ScriptureBurrito standard is a good one.


USX's limitations relative to OSIS are both an advantage and a 
disadvantage. Because USX is more focused on primarily Scriptures, it 
has the advantage that the markup is less ambiguous and more likely to 
be understood by someone else who just read the standard, but had no 
additional information. It is clearly better as an interchange format 
between applications. OSIS is probably better for non-Scripture texts, 
or would be if it had enough software support. Ironically, constraining 
the ways in which data can be represented makes it easier to represent a 
richly formatted Bible. Importing from a ScriptureBurrito could include 
not only the USX Bible text, but metadata for our config files.


Both USX and OSIS lack style sheets that say how data should be 
presented, since both are (mostly) semantic markup. Paratext uses 
external style sheets for this purpose, at least for display within that 
program. Various other publishing paths have their own style sheets, 
which are not really standard.


On 2/18/24 11:41, Robert Hunt wrote:


Just to add a little to Michael Johnson's comments below, OSIS can 
include significantly more metadata than USX specifies (which is 
little more than the book code -- not even whether it's an original 
text (Heb/Greek) or what language translation it is). OSIS can specify 
many other things like version number, licenses and contributors' 
names, etc.


So for a fair comparison with OSIS, I think you'd have to specify USX 
*along with ScriptureBurrito metadata*: see https://www.Burrito.Bible 
 (which is also in the process of being 
supported by the most influential Bible-translation orgs AFAIK).


Blessings,
Robert.
https://OpenEnglishTranslation.Bible 



On 19/02/24 10:19, Michael Johnson wrote:


Thank you, Michael, for the pointer to Jonathan Robie's paper on 
Scriptural markup in the Bible translation community. I think it 
diplomatically states why USX won out over OSIS as the primary and 
best-supported XML standard for representing Scripture.


I really don't expect USFM or USX to go away any time soon, nor do I 
expect OSIS to gain significant traction where it is not in use 
already. I think it is safe to say that Crosswire is the group that 
cares most about OSIS. In many ways, the USX vs. OSIS competition is 
like the old VHS vs. BetaMax video tape competition. (Remember way 
back when video tapes were actually used?) BetaMax was technically 
superior in many ways, but VHS won because of (1) greater support by 
content providers, (2) slightly lower cost of implementation, and (3) 
incompatibility between the formats (i.e. no machine could read both 
formats).


I honestly think that fully supporting USX would be a better use of 
limited resources than tweaking OSIS to overcome its current defects.


For those that don't know, USX is an XML representation of USFM.

USX is well documented and actively maintained at 
https://ubsicap.github.io/usx/. OSIS is abandoned by almost everyone 
by Crosswire. Backup copies of the Schema or on crosswire.org and 
eBible.org, but there is currently no official pumpkin holder to 
maintain it.


USX is fully automatically convertable to and from USFM with no loss 
or human intervention needed. This is not true of pure OSIS for 
technical and philosophical reasons. This is probably the biggest 
reason that OSIS was never supported natively in Paratext, and most 
likely never will be.


USX is the native format of the Every Tribe Every Nation Digital 
Bible Library, which is the highest-quality and best-supported 
repository of Bible translations in the world.


USX and/or USFM are supported by all of the best Bible translation 
software, including open source options. OSIS has no Bible 
translation software support.


USX and/or USFM are supported by numerous Bible publishing options, 
both digitally and for print. OSIS has no significant Bible 
publishing support outside of Crosswire.


USX has organizational support from the most influential Bible 
translation agencies.


Using USX and/or USFM makes versification mapping easier, because 
someone else has already done the work.


There are currently at least 2 reasonable ways to convert from USFM 
or USX to OSIS with minimal losses in formatting. Neither one is 
perfect, but maybe good enough. There is a lot of code assuming OSIS 
inputs to Sword modules, and that could remain, along with GBF and 
TEI, but I can see better quality coming from direct USX support.


If OSIS is good enough as is, fine. But if it isn't, then I suggest 
that it be phased out rather than modified.



On 2/18/24 09:42, Michael H wrote:

Re: Lack of momentum for OSIS.

OSIS as described on wikipedia is owned by a committee including 
United Bible Societies, SIL International, and the Society of 
Biblical Literature.


However, 

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Arnaud Vié]

That's a debate that goes far beyond the scope of the current discussion,
but to be honest I don't understand why USX even exists ^^'

USFM favours easy editing of the files with its simple text tags.
It makes perfect sense for editing bibles, in particular in translation
software.

OSIS favours accurate semantic description of the document structure (with
nested elements and such), making use of the full power of XSD.
It makes perfect sense for published document representation, and for
software that cares about searching and rendering.

USX takes the worst of both worlds : it takes all the heaviness of XML,
while using it to render flat sequences like USFM does. It's basically
"USFM, but heavier". I see no gain compared to USFM, except potentially the
fact that escaping of special characters is made easier (because handled
natively by the XML parser). That's not a whole lot to justify a brand new
format.

My personal conclusion after this exchange would simply be "Great, if
nobody else currently cares, we can take full ownership of OSIS, let's do
it ! " :-D


Le dim. 18 févr. 2024 à 22:20, Michael Johnson  a
écrit :

> Thank you, Michael, for the pointer to Jonathan Robie's paper on
> Scriptural markup in the Bible translation community. I think it
> diplomatically states why USX won out over OSIS as the primary and
> best-supported XML standard for representing Scripture.
>
> I really don't expect USFM or USX to go away any time soon, nor do I
> expect OSIS to gain significant traction where it is not in use already. I
> think it is safe to say that Crosswire is the group that cares most about
> OSIS. In many ways, the USX vs. OSIS competition is like the old VHS vs.
> BetaMax video tape competition. (Remember way back when video tapes were
> actually used?) BetaMax was technically superior in many ways, but VHS won
> because of (1) greater support by content providers, (2) slightly lower
> cost of implementation, and (3) incompatibility between the formats (i.e.
> no machine could read both formats).
>
> I honestly think that fully supporting USX would be a better use of
> limited resources than tweaking OSIS to overcome its current defects.
>
> For those that don't know, USX is an XML representation of USFM.
>
> USX is well documented and actively maintained at
> https://ubsicap.github.io/usx/. OSIS is abandoned by almost everyone by
> Crosswire. Backup copies of the Schema or on crosswire.org and
> eBible.org, but there is currently no official pumpkin holder to maintain
> it.
>
> USX is fully automatically convertable to and from USFM with no loss or
> human intervention needed. This is not true of pure OSIS for technical and
> philosophical reasons. This is probably the biggest reason that OSIS was
> never supported natively in Paratext, and most likely never will be.
>
> USX is the native format of the Every Tribe Every Nation Digital Bible
> Library, which is the highest-quality and best-supported repository of
> Bible translations in the world.
>
> USX and/or USFM are supported by all of the best Bible translation
> software, including open source options. OSIS has no Bible translation
> software support.
>
> USX and/or USFM are supported by numerous Bible publishing options, both
> digitally and for print. OSIS has no significant Bible publishing support
> outside of Crosswire.
>
> USX has organizational support from the most influential Bible translation
> agencies.
>
> Using USX and/or USFM makes versification mapping easier, because someone
> else has already done the work.
>
> There are currently at least 2 reasonable ways to convert from USFM or USX
> to OSIS with minimal losses in formatting. Neither one is perfect, but
> maybe good enough. There is a lot of code assuming OSIS inputs to Sword
> modules, and that could remain, along with GBF and TEI, but I can see
> better quality coming from direct USX support.
>
> If OSIS is good enough as is, fine. But if it isn't, then I suggest that
> it be phased out rather than modified.
>
>
> On 2/18/24 09:42, Michael H wrote:
>
> Re: Lack of momentum for OSIS.
>
> OSIS as described on wikipedia is owned by a committee including United
> Bible Societies, SIL International, and the Society of Biblical
> Literature.
>
> However, this team got together and created the version that is available,
> then almost completely ignored it, and went back to the SFM tagging system
> and then produced USFM, when turned into several more closely related XML
> languages, but has become USX. There was in the UBS/SIL Paratext
> translation program the ability to produce OSIS output until version 8, but
> since about 2016, there is no use or mention of OSIS in Paratext.
>
> A history and analysis of why this is published in Balisage 2021
> conference:
>
>
> https://www.balisage.net/Proceedings/vol26/html/Robie01/BalisageVol26-Robie01.html
>
> Even in 2024, the tagging language USFM remains the "primary" tool to
> encode biblical works at almost all the organizations 

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Arnaud Vié]

Thanks Michael for all this information !
I was not aware of this Copenhagen Alliance's work - I just had a quick
look at the repository you linked, and it seems to cover a significant part
of the requirements I wanted to cover with my proposal, but not all.
I like the format, and the fact that it includes the ability to specify
mappings directly within the json definition.
However, from what I understand, it's not modular : each versification must
still be completely defined in a single file, and mappings are always
relative to the single "org" versification.

Anyway, I'll keep that in mind once I present my general idea here - maybe
I should also present it to this Copenhagen Alliance as a possible
evolution of their format.
Then, the change in OSIS would just be to allow refSystem to point to such
a json file, and for SWORD to allow packaging this file within the SWORD
module (and reading and understanding it, of course) - we wouldn't need to
define yet another standard.

Le dim. 18 févr. 2024 à 21:47, Michael H  a écrit :

> And, It appears "unspecified" is no longer true for the .vrs files.
>
> https://github.com/Copenhagen-Alliance/versification-specification
>
> I don't think it's pulled back into Paratext yet, but this is an actual
> "spec" to look at to understand the USFM ... not USFM, but
> Paratext/UBS/SIL/Bible Translation community approach to mapping
> versifications.
>
> https://github.com/Copenhagen-Alliance/versification-specification
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Robert Hunt]

Just to add a little to Michael Johnson's comments below, OSIS can 
include significantly more metadata than USX specifies (which is little 
more than the book code -- not even whether it's an original text 
(Heb/Greek) or what language translation it is). OSIS can specify many 
other things like version number, licenses and contributors' names, etc.


So for a fair comparison with OSIS, I think you'd have to specify USX 
*along with ScriptureBurrito metadata*: see https://www.Burrito.Bible 
 (which is also in the process of being 
supported by the most influential Bible-translation orgs AFAIK).


Blessings,
Robert.
https://OpenEnglishTranslation.Bible 

On 19/02/24 10:19, Michael Johnson wrote:


Thank you, Michael, for the pointer to Jonathan Robie's paper on 
Scriptural markup in the Bible translation community. I think it 
diplomatically states why USX won out over OSIS as the primary and 
best-supported XML standard for representing Scripture.


I really don't expect USFM or USX to go away any time soon, nor do I 
expect OSIS to gain significant traction where it is not in use 
already. I think it is safe to say that Crosswire is the group that 
cares most about OSIS. In many ways, the USX vs. OSIS competition is 
like the old VHS vs. BetaMax video tape competition. (Remember way 
back when video tapes were actually used?) BetaMax was technically 
superior in many ways, but VHS won because of (1) greater support by 
content providers, (2) slightly lower cost of implementation, and (3) 
incompatibility between the formats (i.e. no machine could read both 
formats).


I honestly think that fully supporting USX would be a better use of 
limited resources than tweaking OSIS to overcome its current defects.


For those that don't know, USX is an XML representation of USFM.

USX is well documented and actively maintained at 
https://ubsicap.github.io/usx/. OSIS is abandoned by almost everyone 
by Crosswire. Backup copies of the Schema or on crosswire.org and 
eBible.org, but there is currently no official pumpkin holder to 
maintain it.


USX is fully automatically convertable to and from USFM with no loss 
or human intervention needed. This is not true of pure OSIS for 
technical and philosophical reasons. This is probably the biggest 
reason that OSIS was never supported natively in Paratext, and most 
likely never will be.


USX is the native format of the Every Tribe Every Nation Digital Bible 
Library, which is the highest-quality and best-supported repository of 
Bible translations in the world.


USX and/or USFM are supported by all of the best Bible translation 
software, including open source options. OSIS has no Bible translation 
software support.


USX and/or USFM are supported by numerous Bible publishing options, 
both digitally and for print. OSIS has no significant Bible publishing 
support outside of Crosswire.


USX has organizational support from the most influential Bible 
translation agencies.


Using USX and/or USFM makes versification mapping easier, because 
someone else has already done the work.


There are currently at least 2 reasonable ways to convert from USFM or 
USX to OSIS with minimal losses in formatting. Neither one is perfect, 
but maybe good enough. There is a lot of code assuming OSIS inputs to 
Sword modules, and that could remain, along with GBF and TEI, but I 
can see better quality coming from direct USX support.


If OSIS is good enough as is, fine. But if it isn't, then I suggest 
that it be phased out rather than modified.



On 2/18/24 09:42, Michael H wrote:

Re: Lack of momentum for OSIS.

OSIS as described on wikipedia is owned by a committee including 
United Bible Societies, SIL International, and the Society of 
Biblical Literature.


However, this team got together and created the version that is 
available, then almost completely ignored it, and went back to the 
SFM tagging system and then produced USFM, when turned into several 
more closely related XML languages, but has become USX. There was in 
the UBS/SIL Paratext translation program the ability to produce OSIS 
output until version 8, but since about 2016, there is no use or 
mention of OSIS in Paratext.


A history and analysis of why this is published in Balisage 2021 
conference:


https://www.balisage.net/Proceedings/vol26/html/Robie01/BalisageVol26-Robie01.html

Even in 2024, the tagging language USFM remains the "primary" tool to 
encode biblical works at almost all the organizations that produced 
OSIS. There is no momentum for that committee to ever meet again. But 
the spec has holes.


https://gitlab.com/cmahte/osis-users-manual-2.1

I started working on updating OSIS, and in the process received a 
reply from someone at ABS or UBS that although the OSIS spec is 
copyrighted and does not contain specific verbiage about reuse, I 
could and should consider it licensed under creative commons BY-SA. 
(At the time, I wasn't 

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Matěj Cepl]

On Sun Feb 18, 2024 at 8:51 PM CET, Matěj Cepl wrote:
> It seems there was something on Sourceforge
> (https://sourceforge.net/p/sword/cvs/), but it is most likely
> gone.

Just for the record, the Sourceforge repo is more recent than SVN
(https://git.cepl.eu/cgit/sword/sword-sf-cvs/).

Best,

Matěj

-- 
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
No matter what happens in the kitchen, never apologize.
  -- Julia Child



E09FEF25D96484AC.asc
Description: application/pgp-keys


signature.asc
Description: PGP signature
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Michael Johnson]

Thank you, Michael, for the pointer to Jonathan Robie's paper on 
Scriptural markup in the Bible translation community. I think it 
diplomatically states why USX won out over OSIS as the primary and 
best-supported XML standard for representing Scripture.


I really don't expect USFM or USX to go away any time soon, nor do I 
expect OSIS to gain significant traction where it is not in use already. 
I think it is safe to say that Crosswire is the group that cares most 
about OSIS. In many ways, the USX vs. OSIS competition is like the old 
VHS vs. BetaMax video tape competition. (Remember way back when video 
tapes were actually used?) BetaMax was technically superior in many 
ways, but VHS won because of (1) greater support by content providers, 
(2) slightly lower cost of implementation, and (3) incompatibility 
between the formats (i.e. no machine could read both formats).


I honestly think that fully supporting USX would be a better use of 
limited resources than tweaking OSIS to overcome its current defects.


For those that don't know, USX is an XML representation of USFM.

USX is well documented and actively maintained at 
https://ubsicap.github.io/usx/. OSIS is abandoned by almost everyone by 
Crosswire. Backup copies of the Schema or on crosswire.org and 
eBible.org, but there is currently no official pumpkin holder to 
maintain it.


USX is fully automatically convertable to and from USFM with no loss or 
human intervention needed. This is not true of pure OSIS for technical 
and philosophical reasons. This is probably the biggest reason that OSIS 
was never supported natively in Paratext, and most likely never will be.


USX is the native format of the Every Tribe Every Nation Digital Bible 
Library, which is the highest-quality and best-supported repository of 
Bible translations in the world.


USX and/or USFM are supported by all of the best Bible translation 
software, including open source options. OSIS has no Bible translation 
software support.


USX and/or USFM are supported by numerous Bible publishing options, both 
digitally and for print. OSIS has no significant Bible publishing 
support outside of Crosswire.


USX has organizational support from the most influential Bible 
translation agencies.


Using USX and/or USFM makes versification mapping easier, because 
someone else has already done the work.


There are currently at least 2 reasonable ways to convert from USFM or 
USX to OSIS with minimal losses in formatting. Neither one is perfect, 
but maybe good enough. There is a lot of code assuming OSIS inputs to 
Sword modules, and that could remain, along with GBF and TEI, but I can 
see better quality coming from direct USX support.


If OSIS is good enough as is, fine. But if it isn't, then I suggest that 
it be phased out rather than modified.



On 2/18/24 09:42, Michael H wrote:

Re: Lack of momentum for OSIS.

OSIS as described on wikipedia is owned by a committee including 
United Bible Societies, SIL International, and the Society of Biblical 
Literature.


However, this team got together and created the version that is 
available, then almost completely ignored it, and went back to the SFM 
tagging system and then produced USFM, when turned into several more 
closely related XML languages, but has become USX. There was in the 
UBS/SIL Paratext translation program the ability to produce OSIS 
output until version 8, but since about 2016, there is no use or 
mention of OSIS in Paratext.


A history and analysis of why this is published in Balisage 2021 
conference:


https://www.balisage.net/Proceedings/vol26/html/Robie01/BalisageVol26-Robie01.html

Even in 2024, the tagging language USFM remains the "primary" tool to 
encode biblical works at almost all the organizations that produced 
OSIS. There is no momentum for that committee to ever meet again. But 
the spec has holes.


https://gitlab.com/cmahte/osis-users-manual-2.1

I started working on updating OSIS, and in the process received a 
reply from someone at ABS or UBS that although the OSIS spec is 
copyrighted and does not contain specific verbiage about reuse, I 
could and should consider it licensed under creative commons BY-SA. 
(At the time, I wasn't seeking to update OSIS, but freely copy from it 
in creating a successor or fork.)


This means that OSIS is both abandoned and available for adoption by a 
successor body.  I've also since moved on from ever producing proposed 
changes to it or a fork myself. IF I ever got far enough along to need 
a formal spec, it would be extensions USFM or to OpenDocument or more 
directly synonymous with that XML.  If you're interested, I'll dig up 
the contact information, and pass it along. But I do have a copy 
re-edited into USFM (or more specifically a draft version of PSFM... 
which means the way tables are built in my text are unusual.) If there 
is an effort to update. I can transform my work into LibreOffice 
Writer format.


I suggest it is time to consider an OSIS 

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Michael H]

And it's important to note that the Copenhagen-Alliance Versification
Specification working group committee includes David Instone-Brewer of
Tyndale House, producers of STEP Bible, which is build on Jsword, and
mentioned elsewhere in this thread.



On Sun, Feb 18, 2024 at 2:41 PM Michael H  wrote:

> And, It appears "unspecified" is no longer true for the .vrs files.
>
> https://github.com/Copenhagen-Alliance/versification-specification
>
> I don't think it's pulled back into Paratext yet, but this is an actual
> "spec" to look at to understand the USFM ... not USFM, but
> Paratext/UBS/SIL/Bible Translation community approach to mapping
> versifications.
>
> https://github.com/Copenhagen-Alliance/versification-specification
>
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Michael H]

And, It appears "unspecified" is no longer true for the .vrs files.

https://github.com/Copenhagen-Alliance/versification-specification

I don't think it's pulled back into Paratext yet, but this is an actual
"spec" to look at to understand the USFM ... not USFM, but
Paratext/UBS/SIL/Bible Translation community approach to mapping
versifications.

https://github.com/Copenhagen-Alliance/versification-specification
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Michael H]

Again, I really mean no offense to anyone with this - in particular to the
> original jsword developer, dmsmith, that did a great work with it until
> 2019.
> I'm worried so much about the status of jsword precisely because I think
> it's a great library, with lots of well designed components, which needs
> just a small refresh to be more easily maintaineable and accessible in the
> modern world.
>
> OSIS - crosswire is the principal user, but as it stands it is an
>> international standard, and not under our control.
>
>
> That's a good point, but is anyone actually still in control ? From what I
> understand, the organisation "bibletechnologies.net" that originally
> defined it has disappeared, and from what I've seen, the only people
> keeping some public knowledge of OSIS are crosswire, and the only projects
> actively using OSIS are crosswire projects (the sword ecosystem).
> When CrossWire created an osis-core mailing list and started maintaining
> amended versions, I think it implicitly recognised that it had become the
> lead authority on the topic. :-)
>
>
>
> Yes, last year we had a discussion on the CrossWire and git topic and you
>> can see the discussion in the mail archives here.
>
>
> Thanks Troy for the link, very interesting !
> I see mostly discussion on the merits of GitHub vs. GitLab. I have no
> definitive opinion between the two : philosophically I'm more inclined to
> use the open source software (so GitLab is good), but in practice my main
> worry in this thread is to improve visibility and attractiveness for
> contributors (on that part, GitHub has the advantage).
> My point is, even if in the end we use GitLab, we should at least update
> the GitHub project to be clean and contain links to the relevant GitLab
> projects, to make it a proper entrypoint.
>
> Regarding OSIS, can you post here what proposal you would like to make? I
>> am sure many people here will have comments on your idea.
>
>
> Thanks for your interest !
> I'm still formalising the proposal (writing an accurate description of all
> the principles and objectives behind it), but I'll open a dedicated thread
> in this mailing list very soon.
>
> Cheers,
>
> Arnaud
>
> Le dim. 18 févr. 2024 à 12:35, Troy A. Griffitts  a
> écrit :
>
>> Dear Arnaud and others,
>>
>> Peter has done a good job summarizing.
>>
>> Yes, last year we had a discussion on the CrossWire and git topic and you
>> can see the discussion in the mail archives here.
>>
>> https://crosswire.org/pipermail/sword-devel/2023-March/subject.hYes, last
>> year we had a discussion on the CrossWire and git topic and you can see the
>> discussion in the mail archives here.tml
>> <https://crosswire.org/pipermail/sword-devel/2023-March/subject.html>
>>
>> Some progress has been made.
>>
>> Regarding OSIS, can you post here what proposal you would like to make? I
>> am sure many people here will have comments on your idea.
>>
>> I am happy for your interest to get involved and for your zeal to see
>> things more visible and active.
>>
>> Welcome,
>>
>> Troy
>>
>>
>> On February 18, 2024 00:57:34 MST, Peter von Kaehne 
>> wrote:
>>
>>> Hi Arnaud,
>>>
>>> It makes sense to understand some things better when seen in history:
>>>
>>> There are three core projects to CrossWire - libsword,  jsword and the
>>> text modules - all others are independent but related users.
>>>
>>> The SVN site for libsword is the current, not old. It is just that very
>>> little changes over long stretches. Libsword is 30 + year old and does
>>> its job. Errors and bugs get corrected , big proposals happen once in a
>>> long while and then come into the code. Development happens in spurts, once
>>> every few years currently - but as users (other projects) are on disparate
>>> platforms consensus is needed.
>>>
>>> Jsword is similarly old, largely feature complete and little changes Two
>>> big projects use it and contribute back to it.
>>>
>>> Substantial internal changes would require consensus across these
>>> projects at the very least.
>>>
>>> Most current development happens in programmes using it and in module
>>> development.
>>>
>>> The GitLab site was created by some of us who create modules for texts
>>> which are in the public domain but have little other exposure
>>>
>>> OSIS - crosswire is the principal user, but as it stands it is an
>>> international standard, and not under our contr

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Matěj Cepl]

On Sun Feb 18, 2024 at 8:57 AM CET, Peter von Kaehne wrote:
> The SVN site for libsword is the current, not old. It is just
> that very little changes over long stretches. Libsword is 30

Is it? The oldest revision in SVN I can find
(https://git.cepl.eu/cgit/sword/commit/?id=44ffa2f5aa5f)) is from
Tue May 4 22:03:32 1999? Is that just the time of CVS2SVN
conversion? Are there archives of the actual CVS somewhere? It
would be nice to include them to git as well.

It seems there was something on Sourceforge
(https://sourceforge.net/p/sword/cvs/), but it is most likely
gone.

> + year old and does its job. Errors and bugs get corrected ,
> big proposals happen once in a long while and then come into
> the code. Development happens in spurts, once every few years
> currently - but as users (other projects) are on disparate
> platforms consensus is needed.

Sorry, I completely agree with Arnaud here. This is just an
excuse: I am quite certain I am not the only one, who just
gave up proposing changes to libsword (e.g., new v11n for the
Protestant Deuterocanonic Bibles) when all my suggestinos were
ignored. There are many projects who are similarly very lightly
manned (to say it mildly; and I am or I was a maintainer on few
of these) and yet there is more life in them than in libsword.

No, I am not saying that just switching to git will fix all our
problems, it is just a sign of them not their cause, but bigger
visibility of the project would certainly not hurt.

Thank you for all your care your spent on the project so far, and
my blessings go with you!

Matěj

-- 
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Reading after a certain age diverts the mind too much from its
creative pursuits. Any man who reads too much and uses his own
brain too little falls into lazy habits of thinking, just as the
man who spends too much time in the theater is tempted to be
content with living vicariously instead of living his own life.
  -- Albert Einstein to The Saturday Evening Post, October 1929



E09FEF25D96484AC.asc
Description: application/pgp-keys


signature.asc
Description: PGP signature
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Fr Cyrille]

Le 18/02/2024 à 20:42, Michael H a écrit :

Re: Lack of momentum for OSIS.

OSIS as described on wikipedia is owned by a committee including 
United Bible Societies, SIL International, and the Society of Biblical 
Literature.


However, this team got together and created the version that is 
available, then almost completely ignored it, and went back to the SFM 
tagging system and then produced USFM, when turned into several more 
closely related XML languages, but has become USX. There was in the 
UBS/SIL Paratext translation program the ability to produce OSIS 
output until version 8, but since about 2016, there is no use or 
mention of OSIS in Paratext.


A history and analysis of why this is published in Balisage 2021 
conference:


https://www.balisage.net/Proceedings/vol26/html/Robie01/BalisageVol26-Robie01.html

Even in 2024, the tagging language USFM remains the "primary" tool to 
encode biblical works at almost all the organizations that produced 
OSIS. There is no momentum for that committee to ever meet again. But 
the spec has holes.


https://gitlab.com/cmahte/osis-users-manual-2.1

I started working on updating OSIS, and in the process received a 
reply from someone at ABS or UBS that although the OSIS spec is 
copyrighted and does not contain specific verbiage about reuse, I 
could and should consider it licensed under creative commons BY-SA. 
(At the time, I wasn't seeking to update OSIS, but freely copy from it 
in creating a successor or fork.)


This means that OSIS is both abandoned and available for adoption by a 
successor body.  I've also since moved on from ever producing proposed 
changes to it or a fork myself. IF I ever got far enough along to need 
a formal spec, it would be extensions USFM or to OpenDocument or more 
directly synonymous with that XML.  If you're interested, I'll dig up 
the contact information, and pass it along. But I do have a copy 
re-edited into USFM (or more specifically a draft version of PSFM... 
which means the way tables are built in my text are unusual.) If there 
is an effort to update. I can transform my work into LibreOffice 
Writer format.


I suggest it is time to consider an OSIS 3, or at least an OSIS 2.2 
spec that is owned by a successor organization instead of 
organizations that effectively abandoned it. That's the missing link 
which would provide a mechanism to actually make changes to the 
standard.  People (including me) keep doing this search and landing at 
Crosswire Bible society as the best option for a new owner. But maybe 
who OWNS can be one of the topics considered by a committee.




On Sat, Feb 17, 2024 at 9:47 AM Arnaud Vié > wrote:


Hi everyone,

Having dived into the whole crosswire ecosystem recently, I'm at
the same time impressed at the quality of the tools provided (in
particular the OSIS standard and the JSword lib, as I've been
working in Java), and worried by what I perceive as a lack of
dynamism around it's development and difficulty to contribute.

By "lack of dynamism" I of course don't mean to criticise the time
anyone spends (as we contribute to a free ecosystem, we all have
lives keeping us busy elsewhere), but rather to highlight how
rough it is for external enthusiastic people to join.
For example, I'd like to contribute evolutions to the OSIS
standard around versification systems, but I have no idea where to
make such proposals, as there is only a mailing list dead since
2015 , a few wiki pages
 and a few downloadable
documents  which are supposedly the
latest version.

I think a lot of that could be improved by making better use of
the crosswire github project , which
is nowadays the first contact most young developers will have with
these crosswire projects.

I'd like to propose a few changes, get your opinions, and
volunteer to execute them if everyone agrees.

  * *Revive the jsword github repository*.
That includes
  o Backporting the relevant changes from the andbible fork

(excluding android-specific stuff - which I already mostly
removed in my last PR there).
  o Setting up a release process to publish the jar on a maven
repository.
  o Setting up a clear branching model and writing clear
contribution guidelines.
  o Having a team of several people familiar with Java
development to review PRs or answer questions in the issue
tracker. I obviously volunteer, but more people is always
the best.

  * *Create a new Git repository for the OSIS specification*.
Must contain :
  o In Git, the OSIS XSD schema, and the 

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Michael H]

Re: Lack of momentum for OSIS.

OSIS as described on wikipedia is owned by a committee including United
Bible Societies, SIL International, and the Society of Biblical
Literature.

However, this team got together and created the version that is available,
then almost completely ignored it, and went back to the SFM tagging system
and then produced USFM, when turned into several more closely related XML
languages, but has become USX. There was in the UBS/SIL Paratext
translation program the ability to produce OSIS output until version 8, but
since about 2016, there is no use or mention of OSIS in Paratext.

A history and analysis of why this is published in Balisage 2021
conference:

https://www.balisage.net/Proceedings/vol26/html/Robie01/BalisageVol26-Robie01.html

Even in 2024, the tagging language USFM remains the "primary" tool to
encode biblical works at almost all the organizations that produced OSIS.
There is no momentum for that committee to ever meet again. But the spec
has holes.

https://gitlab.com/cmahte/osis-users-manual-2.1

I started working on updating OSIS, and in the process received a reply
from someone at ABS or UBS that although the OSIS spec is copyrighted and
does not contain specific verbiage about reuse, I could and should consider
it licensed under creative commons BY-SA. (At the time, I wasn't seeking to
update OSIS, but freely copy from it in creating a successor or fork.)

This means that OSIS is both abandoned and available for adoption by a
successor body.  I've also since moved on from ever producing proposed
changes to it or a fork myself. IF I ever got far enough along to need a
formal spec, it would be extensions USFM or to OpenDocument or more
directly synonymous with that XML.  If you're interested, I'll dig up the
contact information, and pass it along. But I do have a copy re-edited into
USFM (or more specifically a draft version of PSFM... which means the way
tables are built in my text are unusual.) If there is an effort to update.
I can transform my work into LibreOffice Writer format.

I suggest it is time to consider an OSIS 3, or at least an OSIS 2.2 spec
that is owned by a successor organization instead of organizations that
effectively abandoned it.  That's the missing link which would provide a
mechanism to actually make changes to the standard.  People (including me)
keep doing this search and landing at Crosswire Bible society as the best
option for a new owner. But maybe who OWNS can be one of the topics
considered by a committee.

On Sat, Feb 17, 2024 at 9:47 AM Arnaud Vié  wrote:

> Hi everyone,
>
> Having dived into the whole crosswire ecosystem recently, I'm at the same
> time impressed at the quality of the tools provided (in particular the OSIS
> standard and the JSword lib, as I've been working in Java), and worried by
> what I perceive as a lack of dynamism around it's development and
> difficulty to contribute.
>
> By "lack of dynamism" I of course don't mean to criticise the time anyone
> spends (as we contribute to a free ecosystem, we all have lives keeping us
> busy elsewhere), but rather to highlight how rough it is for external
> enthusiastic people to join.
> For example, I'd like to contribute evolutions to the OSIS standard around
> versification systems, but I have no idea where to make such proposals, as
> there is only a mailing list dead since 2015
> , a few wiki pages
>  and a few downloadable
> documents  which are supposedly the latest
> version.
>
> I think a lot of that could be improved by making better use of the
> crosswire github project , which is
> nowadays the first contact most young developers will have with these
> crosswire projects.
>
> I'd like to propose a few changes, get your opinions, and volunteer to
> execute them if everyone agrees.
>
>- *Revive the jsword github repository*.
>That includes
>   - Backporting the relevant changes from the andbible fork
>   
>   (excluding android-specific stuff - which I already mostly removed in my
>   last PR there).
>   - Setting up a release process to publish the jar on a maven
>   repository.
>   - Setting up a clear branching model and writing clear contribution
>   guidelines.
>   - Having a team of several people familiar with Java development to
>   review PRs or answer questions in the issue tracker. I obviously 
> volunteer,
>   but more people is always the best.
>
>   - *Create a new Git repository for the OSIS specification*.
>Must contain :
>   - In Git, the OSIS XSD schema, and the functional specification
>   (basically, the contents of the current manual) in markdown or asciidoc
>   format.
>   So that contributions to the standard may be opened as pull
>   requests, reviewed, 

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[David Haslam]

> I see mostly discussion on the merits of GitHub vs. GitLab. I have no 
> definitive opinion between the two : philosophically I'm more inclined to use 
> the open source software (so GitLab is good), but in practice my main worry 
> in this thread is to improve visibility and attractiveness for contributors 
> (on that part, GitHub has the advantage).
> My point is, even if in the end we use GitLab, we should at least update the 
> GitHub project to be clean and contain links to the relevant GitLab projects, 
> to make it a proper entrypoint.
>
>> Regarding OSIS, can you post here what proposal you would like to make? I am 
>> sure many people here will have comments on your idea.
>
> Thanks for your interest !
> I'm still formalising the proposal (writing an accurate description of all 
> the principles and objectives behind it), but I'll open a dedicated thread in 
> this mailing list very soon.
>
> Cheers,
>
> Arnaud
>
> Le dim. 18 févr. 2024 à 12:35, Troy A. Griffitts  a 
> écrit :
>
>> Dear Arnaud and others,
>>
>> Peter has done a good job summarizing.
>>
>> Yes, last year we had a discussion on the CrossWire and git topic and you 
>> can see the discussion in the mail archives here.
>>
>> [https://crosswire.org/pipermail/sword-devel/2023-March/subject.hYes, last 
>> year we had a discussion on the CrossWire and git topic and you can see the 
>> discussion in the mail archives 
>> here.tml](https://crosswire.org/pipermail/sword-devel/2023-March/subject.html)
>>
>> Some progress has been made.
>>
>> Regarding OSIS, can you post here what proposal you would like to make? I am 
>> sure many people here will have comments on your idea.
>>
>> I am happy for your interest to get involved and for your zeal to see things 
>> more visible and active.
>>
>> Welcome,
>>
>> Troy
>>
>> On February 18, 2024 00:57:34 MST, Peter von Kaehne  wrote:
>>
>>> Hi Arnaud,
>>>
>>> It makes sense to understand some things better when seen in history:
>>>
>>> There are three core projects to CrossWire - libsword, jsword and the text 
>>> modules - all others are independent but related users.
>>>
>>> The SVN site for libsword is the current, not old. It is just that very 
>>> little changes over long stretches. Libsword is 30 + year old and does its 
>>> job. Errors and bugs get corrected , big proposals happen once in a long 
>>> while and then come into the code. Development happens in spurts, once 
>>> every few years currently - but as users (other projects) are on disparate 
>>> platforms consensus is needed.
>>>
>>> Jsword is similarly old, largely feature complete and little changes Two 
>>> big projects use it and contribute back to it.
>>>
>>> Substantial internal changes would require consensus across these projects 
>>> at the very least.
>>>
>>> Most current development happens in programmes using it and in module 
>>> development.
>>>
>>> The GitLab site was created by some of us who create modules for texts 
>>> which are in the public domain but have little other exposure
>>>
>>> OSIS - crosswire is the principal user, but as it stands it is an 
>>> international standard, and not under our control. We do maintain some 
>>> internal amendments as the standard has not been updated otherwise since 
>>> creation.
>>>
>>> Peter
>>>
>>> Sent from [Outlook for iOS](https://aka.ms/o0ukef)
>>>
>>> ---
>>>
>>> From: sword-devel  on behalf of Arnaud 
>>> Vié <[unas.zole+a...@gmail.com](mailto:unas.zole%2ba...@gmail.com)>
>>> Sent: Saturday, February 17, 2024 11:02 pm
>>> To: SWORD Developers' Collaboration Forum 
>>> Subject: Re: [sword-devel] Making better use of the CrossWire GitHub 
>>> project ?
>>>
>>> Thanks Matej for all the information !
>>> (and your git mirrror, that will be quite helpful :-) )
>>>
>>> Is the gitlab project referenced anywhere on the crosswire website ? 
>>> Because I've been looking all over and only found the svn link ^^'
>>> That's exactly the kind of problems I'm talking about when I say the 
>>> project's visibility could be improved, to make it more possible for new 
>>> people to get interested and join !
>>> I don't have anything against GitLab, but GitHub is by far more popular. 
>>> People can randomly search for pro

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Arnaud Vié]

 principles and objectives behind it), but I'll open a dedicated thread
in this mailing list very soon.

Cheers,

Arnaud

Le dim. 18 févr. 2024 à 12:35, Troy A. Griffitts  a
écrit :

> Dear Arnaud and others,
>
> Peter has done a good job summarizing.
>
> Yes, last year we had a discussion on the CrossWire and git topic and you
> can see the discussion in the mail archives here.
>
> https://crosswire.org/pipermail/sword-devel/2023-March/subject.hYes, last
> year we had a discussion on the CrossWire and git topic and you can see the
> discussion in the mail archives here.tml
> <https://crosswire.org/pipermail/sword-devel/2023-March/subject.html>
>
> Some progress has been made.
>
> Regarding OSIS, can you post here what proposal you would like to make? I
> am sure many people here will have comments on your idea.
>
> I am happy for your interest to get involved and for your zeal to see
> things more visible and active.
>
> Welcome,
>
> Troy
>
>
> On February 18, 2024 00:57:34 MST, Peter von Kaehne 
> wrote:
>
>> Hi Arnaud,
>>
>> It makes sense to understand some things better when seen in history:
>>
>> There are three core projects to CrossWire - libsword,  jsword and the
>> text modules - all others are independent but related users.
>>
>> The SVN site for libsword is the current, not old. It is just that very
>> little changes over long stretches. Libsword is 30 + year old and does
>> its job. Errors and bugs get corrected , big proposals happen once in a
>> long while and then come into the code. Development happens in spurts, once
>> every few years currently - but as users (other projects) are on disparate
>> platforms consensus is needed.
>>
>> Jsword is similarly old, largely feature complete and little changes Two
>> big projects use it and contribute back to it.
>>
>> Substantial internal changes would require consensus across these
>> projects at the very least.
>>
>> Most current development happens in programmes using it and in module
>> development.
>>
>> The GitLab site was created by some of us who create modules for texts
>> which are in the public domain but have little other exposure
>>
>> OSIS - crosswire is the principal user, but as it stands it is an
>> international standard, and not under our control. We do maintain some
>> internal amendments as the standard has not been updated otherwise since
>> creation.
>>
>>
>>
>>
>> Peter
>>
>> Sent from Outlook for iOS <https://aka.ms/o0ukef>
>>
>> --
>> *From:* sword-devel  on behalf of
>> Arnaud Vié 
>> *Sent:* Saturday, February 17, 2024 11:02 pm
>> *To:* SWORD Developers' Collaboration Forum 
>> *Subject:* Re: [sword-devel] Making better use of the CrossWire GitHub
>> project ?
>>
>> Thanks Matej for all the information !
>> (and your git mirrror, that will be quite helpful :-) )
>>
>> Is the gitlab project referenced anywhere on the crosswire website ?
>> Because I've been looking all over and only found the svn link ^^'
>> That's exactly the kind of problems I'm talking about when I say the
>> project's visibility could be improved, to make it more possible for new
>> people to get interested and join !
>> I don't have anything against GitLab, but GitHub is by far more popular.
>> People can randomly search for projects on GitHub - but virtually no one
>> searches for projects on GitLab if they don't already know that the project
>> is hosted there. So if we use GitLab for all development, we should at
>> least put some links in the GitHub project description and on the crosswire
>> website to tell people where to go.
>>
>>
>> Regarding the GitLab project, just like pinoaffe I can't see any
>> repository related to the OSIS specification, only bible modules and a
>> "script" repo.
>>
>>
>> And by the way, given the number of module (ie "data") repositories
>> present, another suggestion I can make is to keep the repositories related
>> to core functionality (spec, librairies, etc.) in a separate project, as
>> their contributors will likely be very different. As a developer, finding a
>> code repository in the middle of 6 pages of data repos is not very
>> convenient.
>> In that regards, it could even make sense to keep gitlab for data, and
>> use github for code - or just create a separate gitlab project for code
>> repositories, whatever people prefer.
>>
>>
>> Finally, for jsword, to be honest I'm not really worried about its
&g

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Troy A. Griffitts]

Dear Arnaud and others,

Peter has done a good job summarizing.

Yes, last year we had a discussion on the CrossWire and git topic and you can 
see the discussion in the mail archives here.

https://crosswire.org/pipermail/sword-devel/2023-March/subject.html

Some progress has been made.

Regarding OSIS, can you post here what proposal you would like to make? I am 
sure many people here will have comments on your idea.

I am happy for your interest to get involved and for your zeal to see things 
more visible and active.

Welcome,

Troy

On February 18, 2024 00:57:34 MST, Peter von Kaehne  wrote:
>___
>sword-devel mailing list: sword-devel@crosswire.org
>http://crosswire.org/mailman/listinfo/sword-devel
>Instructions to unsubscribe/change your settings at above page

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Peter von Kaehne]

  
  
  

Hi Arnaud,It makes sense to understand some things better when seen in history:There are three core projects to CrossWire - libsword,  jsword and the text modules - all others are independent but related users. The SVN site for libsword is the current, not old. It is just that very little changes over long stretches. Libsword is 30 + year old and does its job. Errors and bugs get corrected , big proposals happen once in a long while and then come into the code. Development happens in spurts, once every few years currently - but as users (other projects) are on disparate platforms consensus is needed. Jsword is similarly old, largely feature complete and little changes Two big projects use it and contribute back to it. Substantial internal changes would require consensus across these projects at the very least. Most current development happens in programmes using it and in module development. The GitLab site was created by some of us who create modules for texts which are in the public domain but have little other exposure OSIS - crosswire is the principal user, but as it stands it is an international standard, and not under our control. We do maintain some internal amendments as the standard has not been updated otherwise since creation. Peter
Sent from Outlook for iOS
  

 From: sword-devel  on behalf of Arnaud Vié Sent: Saturday, February 17, 2024 11:02 pmTo: SWORD Developers' Collaboration Forum Subject: Re: [sword-devel] Making better use of the CrossWire GitHub project ? Thanks Matej for all the information !(and your git mirrror, that will be quite helpful :-) )Is the gitlab project referenced anywhere on the crosswire website ? Because I've been looking all over and only found the svn link ^^'That's exactly the kind of problems I'm talking about when I say the project's visibility could be improved, to make it more possible for new people to get interested and join !I don't have anything against GitLab, but GitHub is by far more popular. People can randomly search for projects on GitHub - but virtually no one searches for projects on GitLab if they don't already know that the project is hosted there. So if we use GitLab for all development, we should at least put some links in the GitHub project description and on the crosswire website to tell people where to go.Regarding the GitLab project, just like pinoaffe I can't see any repository related to the OSIS specification, only bible modules and a "script" repo.And by the way, given the number of module (ie "data") repositories present, another suggestion I can make is to keep the repositories related to core functionality (spec, librairies, etc.) in a separate project, as their contributors will likely be very different. As a developer, finding a code repository in the middle of 6 pages of data repos is not very convenient.In that regards, it could even make sense to keep gitlab for data, and use github for code - or just create a separate gitlab project for code repositories, whatever people prefer.Finally, for jsword, to be honest I'm not really worried about its "organizational" status : after 5 years without breathing it's unambiguously dead.My request is to mostly to try to reach whoever has admin rights on the "crosswire" GitHub project, and see if they would be willing to let me take over jsword to refresh it :-)Le sam. 17 févr 2024 à 21:12, Matěj Cepl <mc...@cepl.eu> a écrit :On Sat Feb 17, 2024 at 4:46 PM CET, Arnaud Vié wrote:
> I think a lot of that could be improved by making better use of the
> crosswire github project <https://github.com/crosswire>, which is nowadays
> the first contact most young developers will have with these crosswire
> projects.

https://github.com/crosswire is mostly dead. There
is more life (especially for modules) at
https://gitlab.com/crosswire-bible-society and then there is
another GitLab at https://git.crosswire.org/ (for contributors
only).

>    - *Revive the jsword github repository*.

jsword is organizationally in many aspects a separate project from libsword

>       - *Create a new Git repository for the OSIS specification*.

See on gitlab.

>       - Ideally, I'd also suggest *moving the C++ sword code to github*.
>    Having it only on an old SVN repo
>    <https://crosswire.org/svn/sword/trunk/>, not browsable or searchable
>    online, really harms its visibility. I used a little bit of SVN while in
>    engineering school 12 years ago, but I doubt that most young devs nowadays
>    even know about it.

I don’t even comment on this one any more (just mirror it to
https://git.cepl.eu/cgit/sword/), because where there is no
advice, there is no help.

Best,

Matěj

-- 
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Why should I travel, when I’m already there?
    -- Bostonian lady, when being asked why she never v

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Arnaud Vié]

Thanks Matej for all the information !
(and your git mirrror, that will be quite helpful :-) )

Is the gitlab project referenced anywhere on the crosswire website ?
Because I've been looking all over and only found the svn link ^^'
That's exactly the kind of problems I'm talking about when I say the
project's visibility could be improved, to make it more possible for new
people to get interested and join !
I don't have anything against GitLab, but GitHub is by far more popular.
People can randomly search for projects on GitHub - but virtually no one
searches for projects on GitLab if they don't already know that the project
is hosted there. So if we use GitLab for all development, we should at
least put some links in the GitHub project description and on the crosswire
website to tell people where to go.


Regarding the GitLab project, just like pinoaffe I can't see any repository
related to the OSIS specification, only bible modules and a "script" repo.


And by the way, given the number of module (ie "data") repositories
present, another suggestion I can make is to keep the repositories related
to core functionality (spec, librairies, etc.) in a separate project, as
their contributors will likely be very different. As a developer, finding a
code repository in the middle of 6 pages of data repos is not very
convenient.
In that regards, it could even make sense to keep gitlab for data, and use
github for code - or just create a separate gitlab project for code
repositories, whatever people prefer.


Finally, for jsword, to be honest I'm not really worried about its
"organizational" status : after 5 years without breathing it's
unambiguously dead.
My request is to mostly to try to reach whoever has admin rights on the
"crosswire" GitHub project, and see if they would be willing to let me take
over jsword to refresh it :-)


Le sam. 17 févr. 2024 à 21:12, Matěj Cepl  a écrit :

> On Sat Feb 17, 2024 at 4:46 PM CET, Arnaud Vié wrote:
> > I think a lot of that could be improved by making better use of the
> > crosswire github project , which is
> nowadays
> > the first contact most young developers will have with these crosswire
> > projects.
>
> https://github.com/crosswire is mostly dead. There
> is more life (especially for modules) at
> https://gitlab.com/crosswire-bible-society and then there is
> another GitLab at https://git.crosswire.org/ (for contributors
> only).
>
> >- *Revive the jsword github repository*.
>
> jsword is organizationally in many aspects a separate project from
> libsword.
>
> >   - *Create a new Git repository for the OSIS specification*.
>
> See on gitlab.
>
> >   - Ideally, I'd also suggest *moving the C++ sword code to github*.
> >Having it only on an old SVN repo
> >, not browsable or searchable
> >online, really harms its visibility. I used a little bit of SVN while
> in
> >engineering school 12 years ago, but I doubt that most young devs
> nowadays
> >even know about it.
>
> I don’t even comment on this one any more (just mirror it to
> https://git.cepl.eu/cgit/sword/), because where there is no
> advice, there is no help.
>
> Best,
>
> Matěj
>
> --
> http://matej.ceplovi.cz/blog/, @mcepl@floss.social
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> Why should I travel, when I’m already there?
> -- Bostonian lady, when being asked why she never visited
> other places than Boston
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[pinoaffe]

Matěj Cepl  writes:

> [[PGP Signed Part:Undecided]]
> On Sat Feb 17, 2024 at 4:46 PM CET, Arnaud Vié wrote:
>> I think a lot of that could be improved by making better use of the
>> crosswire github project , which is nowadays
>> the first contact most young developers will have with these crosswire
>> projects.
>
> https://github.com/crosswire is mostly dead. There
> is more life (especially for modules) at
> https://gitlab.com/crosswire-bible-society and then there is
> another GitLab at https://git.crosswire.org/ (for contributors
> only).

>>   - *Create a new Git repository for the OSIS specification*.
> See on gitlab.
I couldn't find anything that looks like the OSIS spec on the public
gitlab, so I'm guessing this is on the contributor-only gitlab?  If so,
how does one get access to it?

And how could I get access to the wiki?

Kind regards,
pinoaffe
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Making better use of the CrossWire GitHub project ?

[Matěj Cepl]

On Sat Feb 17, 2024 at 4:46 PM CET, Arnaud Vié wrote:
> I think a lot of that could be improved by making better use of the
> crosswire github project , which is nowadays
> the first contact most young developers will have with these crosswire
> projects.

https://github.com/crosswire is mostly dead. There
is more life (especially for modules) at
https://gitlab.com/crosswire-bible-society and then there is
another GitLab at https://git.crosswire.org/ (for contributors
only).

>- *Revive the jsword github repository*.

jsword is organizationally in many aspects a separate project from libsword.

>   - *Create a new Git repository for the OSIS specification*.

See on gitlab.

>   - Ideally, I'd also suggest *moving the C++ sword code to github*.
>Having it only on an old SVN repo
>, not browsable or searchable
>online, really harms its visibility. I used a little bit of SVN while in
>engineering school 12 years ago, but I doubt that most young devs nowadays
>even know about it.

I don’t even comment on this one any more (just mirror it to
https://git.cepl.eu/cgit/sword/), because where there is no
advice, there is no help.

Best,

Matěj

-- 
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Why should I travel, when I’m already there?
-- Bostonian lady, when being asked why she never visited
other places than Boston



E09FEF25D96484AC.asc
Description: application/pgp-keys


signature.asc
Description: PGP signature
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page