[Pkg-crosswire-devel] On 1.5.12 and our own Debian package repo

[DM Smith]

Sorry for top-posting. (Well, not too sorry.) But this is more of a  
comment as a whole on the nature of SWORD at this time.

While I am a contributor to SWORD, it has been focused on those parts  
tied to module creation and their proper rendering. My SWORD  
contribution is small. My true effort is with JSword.

With the release of 1.5.11 there was a renewed verbal commitment to  
release early and often. Bug fixes were coming in at such a rate that  
it made sense to prepare a 1.5.12 release several months ago. With  
active development on various front-ends resulting in frequent  
releases, the urgency of more frequent releases of the SWORD library  
was expressed.

The development model for SWORD has been to work in trunk, with a  
small group with commit privs. There has been no branching for as long  
as I remember.

We had been promising to work on alternate versification "real soon".  
This was started a few months ago. The design is solid and promises to  
be speedy. There are a few bugs that need to be worked out. But the  
problem is that it should have been done in a branch or a branch  
should have been created for bug fixes. The change was large enough  
that in one fashion or another it is/was disruptive. This did not make  
people happy and this was voiced in sword-devel and probably on irc  
#sword.

Some, perhaps many, (I don't know) felt that 1.5.12 should consist of  
everything but alternate versification and that av11n should be a  
separate later release. I think these off-by-one editions of 1.5.11/12  
are a response to that. I think calling it 1.5.12 is viewed as what  
was implicitly promised. But perhaps, given the naming convention of  
SWORD, it should be 1.5.11.1.

Once av11n is done, I expect that the development model will work once  
again.

While I don't know, having not looked, what the bpbible or xiphos  
patched 1.5.11 is, the patches other than av11n have been small,  
dealing with specific problems and opportunities. I suspect that what  
is available for bpbible is solid. I think it represents the branch  
that should have happened. If they can produce the documentation (i.e.  
changes.txt) for it and one or more patches against the 1.5.11 tag, I  
would probably go for it.

In Him,
	DM

On Apr 1, 2009, at 8:54 PM, Jonathan Marsden wrote:

> Matthew Talbert wrote:
>
>> Another frontend, BPBible, has released their own bugfix 1.5.12
>> version. ...
>
> Aha, so we're re-hashing an idea that has already been (somewhat)
> implemented!  OK.  Questions:
>
> (a) How can someone in good conscience call this 1.5.12, since 1.5.12
> has not been released yet?  Is this a group of coders with prophetic
> gifts???  No-one on earth knows precisely what other new stuff will  
> find
> its way into the real official SWORD 1.5.12 in "a few months".  So,  
> that
> tarball should probably be labelled based on the fact that it came  
> from
> SWORD svn, and the date it was extracted from there, so
> sword-1.5.11.svn20090402.tar.gz might be OK.  This tells the user
> exactly what they are getting, up front.  Calling this file 1.5.12 is,
> in my view, misleading and should be strongly discouraged.
>
>> Due to some other shortcomings of sword on Windows, we are
>> already using a heavily patched version as it is. You can get this
>> version here: http://code.google.com/p/bpbible/downloads/list.
>
> (b) What exactly *is* this code?  I grabbed
> http://bpbible.googlecode.com/files/sword-1.5.12.tar.gz which looks  
> like
> the right kind of file... but it has *no* indications in it that I can
> find that it is an unofficial modification of the original.  INSTALL,
> README etc files are all unchanged.  Surely this is an unhelpful
> approach to be taking -- at minimum one should document what was  
> changed
> and why, and specifically where the original came from (what  
> revision of
> what branch of what svn repository)...
>
> (c) How exactly does the file
> http://bpbible.googlecode.com/files/sword.patch relate to this  
> tarball,
> if at all? It's name is too generic to be really informative, IMO.
> sword-1.5.11-fix-for-unicode-filenames.patch might be great (if that  
> is
> what the patchset does!).
>
>> The only other issue is to create some method to "fix" the personal
>> commentaries that were created before the patch. I don't understand  
>> it
>> nearly enough to know how to go about doing that.
>
> On 64bit Ubuntu I cannot create a Personal commentary using 1.5.11, or
> at least, not very usefully -- I can create one, but I can never  
> edit a
> comment I have made on a given verse!  The edited comment ends up in a
> file whose name is \r\n (carriage return line feed, hex 0x0D 0x0A) and
> which is not visible to or used by the application.
>
> Unless this is already fixed, or the issue is unique to my system
> somehow, worrying about converting old 32bit commentaries to 64bit  
> ones
> seems premature to me... new installations on a 64bit OS are simply
> broken in this regard, as far as I can tell, under SWORD 1.5.11.  This
> is a very user-visible bug, and it could be somewhat distressing if a
> user types in a lengthy comment edit or three and saves them, and only
> later discovers they "did not save".  It's like a word processor that
> doesn't really save your carefully edited document!
>
> The way forward:
>
> The apparent total lack of documentation for both the tarball and the
> patch file makes me extremely wary of using either of them...  
> hopefully
> this can be remedied?  Who would we ask about that?
>
> For example, if the tarball included the a shell script that goes  
> out to
> the svn repo and grabs the code so as to pick up exactly what this
> tarball uses, for example, and a README (README.tarball?   
> README.first?
> whatever!) that explains how and why the tarball was created, and  
> which
> library bugs it is intended to address, that would  be extremely  
> helpful
> documentation to have included.
>
> Lastly: The very fact that packagers and front end developers are
> finding it necessary to do this kind of thing at all should be a very
> loud wake-up call to the SWORD team that something is badly wrong  
> here.
> Sorry if that is overly blunt, but clearly the needs of the developer
> community who are their primary "customers" are not being met by what
> they are releasing, or this sort of thing simply would not be  
> happening.
>
> Jonathan
>
> _______________________________________________
> Pkg-crosswire-devel mailing list
> Pkg-crosswire-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-crosswire-devel