[sword-devel] New public git mirror of Sword SVN trunk and why

[Greg Hellings]

On Mon, Dec 17, 2012 at 11:11 PM, Troy A. Griffitts
<scribe at crosswire.org> wrote:
> I deserve the rebuke for the release schedule. The release schedule was not
> even mentioned in the email to which I responded.

Are you the only person capable of making a release? I remember talk,
I believe it was in sword-devel, about designating another
person/persons to be the release maintainers because you focus mainly
on development. Cutting a 1.6 branch (or a 1.7 now) and giving
maintenance of that branch and release privileges to a few other
people so that they can maintain a regular release schedule
independent of your commitments. Such a person could even have the
privilege of cutting a new branch when the time is right and would be
responsible for back-porting trunk fixes to the release branch.

This has become a regular thing - pleading for a release, seeing the
promised date slip by, and then gradually upping the level of
antagonism until one comes out. It would be great to see this shared
with people who are willing to commit to it.

>
> The NASB ball was dropped by at least 2 volunteers before I personally took
> the task to finally make it happen (unwillingly, but I did commit and spend
> quite a bit of time on it, so I deserve the rebuke).

The two other volunteers are a moot point by now. It has been years
since you took it onto your plate. You said you've put quite a lot of
time into it. Where is the evidence? There is at least one user who
used to come into IRC monthly and ask about it. I never saw you reply
to him. There's a resounding silence on the topic.

What level of coaxing and prodding will bring this about? Those few of
us who are willing to risk goodwill over getting new releases out feel
we will be treading awfully dangerously if we push our luck on too
many topics. We talk sometimes about "pumpkin holders" in this list
and you're very nearly a pumpkin patch. I've offered at least once to
take this on. I always see myself as floating somewhere intermediate
between a developer and a module creator. If NASB needs a little of
both, then that's exactly what I like to focus on.

>
> I have been following the discussion on the SFTP patch and hadn't seen it
> come to a conclusion yet regarding what might be necessary to detect SSL
> support in cURL. I don't feel I've been negligent with this.

I replied in the SFTP thread to this with what I've found so far.

>
> I have no sympathy and honestly think the email Jaak sent was rebellious by
> nature, having never had a patch submitted by Jaak, nor any recent complaint
> or correspondence, along with the accusation of issues with "code quality"
> being the reason for the fork.
>
> I take the criticism I deserve, but none of your valid criticisms have
> anything to do with the original thread.
>
> Regarding release schedules, our private email conversation, Karl, were
> productive and I thought I had outlined a plan to you. I accept the
> accusation of a deficiency in release times. I tend to be a perfectionist
> and want to get everything in that I know is pending before a release, we
> keep SVN very stable-- worst case, packagers already apply patches to our
> releases and can easily release a distro package from HEAD if they choose--
> but I told you I would move forward with a plan to settle with what we have
> in HEAD now and release unless we had warranted pending items from an
> actively developed solution to a problem voiced. I'm not sure why the public
> criticism now, but accepted.
>
> Feel free to publicly vent your frustrations about release schedules, but
> please start a thread that warrants constructive conversation rather than
> the heavily loaded, non-constructive, generic insults expressed by a
> non-contributor which started this thread.

So in this thread I see two currents of discontent:
1) The barrier to entry is too high. Jaak wants to know how to become
a SWORD contributor. He wants to know how to submit patches, branches,
and fixes for problems he sees in the code. This list has brought up
the following multiple times:
a) The website is somewhat of a mess. We have a decent path for a
developer to find the location of our SVN, or to download releases.
Not much else, etc. This is a whole can of worms itself as we've
discovered and let's not re-visit that issue in this discussion. It
has proven impossible to rework the site by committee/too many
cooks/etc. Maybe someone just has to be deignated The Website Guru and
given privileges to implement updates over the protestations of the
rest of us.
b) Lack of exposure of documentation. Yes, I maintain the Doxygen
files in my personal space on crosswire.org and they're linked from
the wiki. But that's where most of the documentation stops. You had
started a series of "Learn to love the API" or whatever it was
messages - were those moved to the site somewhere? There's still no
mention of the wiki anywhere on the site that I can find. At this
point it even has some helpful material in it and I reference it every
time I create a new module conf file and for certain other things.
c) Lack of an easy path to make contributions. Through the official
JIRA? It shows more than half of existing API bugs are still open and
of those which are no longer open, only 7 are listed as resolved. Last
30 days shows no action. If this is the official path, it doesn't look
like it. Is it through the mailing list? This is an easy way for
patches to be lost or forgotten. We've seen it happen before (I know
I'm bad about this when CMake patches come in through the list). I
know that it's through the mailing list with repeated prodding if the
patch falls off the radar, but that's not always the friendliest
method. Have you seen the push/pull requests with visual diffs that
you can get on git and Bazaar and Mercurial sites? Then there's also a
standard place to see outstanding pull requests, just like a bug
system.

Your initial response to Jaak's complaint of this barrier was to point
out that he hasn't crossed this barrier. That's his exact complaint.

2) Is there really incentive to commit back to the engine if, once you
cross the barrier to entry your fix might or might not ever see the
light of day in a release tarball? The issues I brought up along this
line were issues I've seen mentioned multiple times in IRC. They may
not have been explicit in Jaak's initial message, but I wanted to be
sure you understood they are part of his underlying concern. Some of
the bugs that he cites as being low quality code in the engine are
bugs which are fixed in SVN HEAD. But how could he know that when
BibleTime is committed to only releasing against released versions of
SWORD and the latest SWORD is over two years old?

I'm happy to use SVN all day long because I do maintain a part of our
build system and I've been trying to allow some Wycliffe users easier
access to private repositories. You, DM, Chris, are all happy to use
SVN because you're developing on the engine or the utilities or such.
Karl is happy to use SVN so he can cut a new Xiphos release with the
latest and greatest features when the engine makes a new release.
Others on this list are happy to use SVN for similar reasons as well.
But packagers aren't usually happy to rely on it.

And if BibleTime can't rely on SWORD to produce a feature that gets
upstreamed and then never released, what incentive does Jaak have to
cross that barrier? He's better off to fork the project, make his own
changes and updates, and know for sure that his changes will see
daylight.

So those are my constructive suggestions: lower the barrier by
designating an official DVCS clone of SWORD where you (or one of the
other core contributors) are comfortable pulling from and committing
back to the engine when a branch is right. Keep improving the
documentation (a constant complaint in all software!), and take one of
the commiters to the engine who is willing to maintain branches,
either in Subversion or on the official DVCS mirror, and make regular
releases from that.

--Greg

>
> Troy