On Mon, Dec 17, 2012 at 11:11 PM, Troy A. Griffitts <scr...@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 _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
