[sword-devel] I implore you...
jaak at ristioja.ee
Sun Jun 9 14:55:02 MST 2013
-----BEGIN PGP SIGNED MESSAGE-----
On 09.06.2013 23:21, Troy A. Griffitts wrote:
> I don't think other developers are getting ignored. Please be
> specific. Just because I don't accept a patch doesn't mean a
> developer is getting ignored.
> In fact, many times trying to make this release, when people
> complain that we need something fixed for this release, I ask for a
> simple testsuite addition to show the problem and desired result,
> and don't get a response.
> I don't believe the problem is as you think it is Jaak. Many
> people whine about this or that. Not all whine for things to go in
> the same direction.
> Everyone whines for a release but not everyone is willing to help
> submit tests and then fixes for those tests.
> You stated that you would get involved to help, but you only
> submit things for which I previously told you I wasn't interested
> in accepting (worrying about pedantic warnings whose changes often
> make the code less readable and do nothing to improve any of the
> real problems for the end user. Though I do appreciate a few of
> the warning fixes you submitted, a few being actual bug fixed too
> (thank you)-- I'm just ranting right now.)
As a BibleTime developer, I want to available tools (-Wall, -Wextra,
cppcheck, etc) to fix any errors in my code. Due to the Sword header
files which generate a lot of warnings this task is VERY inconvenient.
For example, when I compile the whole of BibleTime with GCC, I get 549
warnings from Sword headers (mostly for unused arguments) - how am I
supposed to find the warnings relevant for BibleTime? This alone often
makes it a pain to develop BibleTime and gives me enough reason to
want to fork Sword.
Turning on and fixing pedantic warnings will help find real bugs.
FACT! Forcing developers to work blindfolded will not help anyone.
The same tools can be used to find bugs in Sword code, and SHOULD
regularly be used for this purpose to ensure code quality. As is
obvious these are currently NOT BEING USED by Sword developers.
However, when things eventually break, users complain to the BibleTime
project. Hence, it is also in the interests of front-ends to ensure
that the code of Sword is of good quality. Again - if Sword won't work
to ensure this and wont let us in to fix things, we have another
reason to fork.
This again leads us to the issue of attracting new developers to
Sword. I don't want to write on this more than necessary to provide a
small argument for my conclusion. Afaik the current situation isn't
working well. Biggest obstacles for me personally include working
blindfolded, submitting patches by e-mail and not getting enough
feedback for (ignored) patches and other emails.
To conclude - maybe its just me, but altogether I really feel it were
easier to maintain a parallel fork (at minimal to provide set of
patches) than to waste my time writing long letters trying to make
this relationship work in its current form. I accept whatever path the
Sword project takes, but if it's not enough for the needs of BibleTime
and our devs, we will make our own choices as well.
The BibleTime team
PS: I apologize if this late-night response is incomprehensible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the sword-devel