Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On 08/16/2013 06:37 PM, Greg Hellings wrote: Well thanks to the magic of git, you wouldn't lose anything except your log in functionality if github ever goes away. Oh, you'd also lose issues information about who branched your code, etc, but you wouldn't know that with gitorious either. The only thing you'd lose is that pretty wrapper around it. Anyway, the point of my original post was not github v. gitorious, and I have emphasized that current location of the repo really doesn't matter. Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Pain is inevitable, but misery is optional. We cannot avoid pain, but we can avoid joy. -- Tim Hansel signature.asc Description: OpenPGP digital signature ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
Not sure what you mean about free vs proprietary. We're not paying anything to have the CrossWire organisation in github. Chris On 14 Aug 2013 15:54, Matěj Cepl mc...@redhat.com wrote: On 12/17/2012 09:13 PM, Jaak Ristioja wrote: I created a new git mirror of the SVN trunk of Sword at gitorious: Gitorious web page: https://gitorious.org/sword-svn-mirrors/trunk I haven't been satisfied with this mirror (not proper names in git fashion, no branches, and no tags), so I have created IMHO a more proper one on https://gitorious.org/sword/sword I know there is an organization on https://github.com/crosswire which has been already used by JSword folks, but let me just say that I prefer free software hosting over proprietary ones. Also, with DVCS it doesn't matter that much which server the repository is currently hosted on, it can be transferred to github easily if the wish arises. I am certainly willing to add more collaborators to the repo or create sword-maintainers team. This repo should be automatically mirrored each day from SVN. Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC In the government of this Commonwealth, the legislative department shall never exercise the executive and judicial powers, or either of them: The executive shall never exercise the legislative and judicial powers, or either of them: The judicial shall never exercise the legislative and executive powers, or either of them: to the end it may be a government of laws and not of men. -- John Adams in the Article XXXth of the Constitution of the Commonwealth of Massachusetts ___ 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 ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
I guess it's about githubs source code isn't entirely free software. On Fri, Aug 16, 2013 at 8:23 AM, Chris Burrell ch...@burrell.me.uk wrote: Not sure what you mean about free vs proprietary. We're not paying anything to have the CrossWire organisation in github. Chris On 14 Aug 2013 15:54, Matěj Cepl mc...@redhat.com wrote: On 12/17/2012 09:13 PM, Jaak Ristioja wrote: I created a new git mirror of the SVN trunk of Sword at gitorious: Gitorious web page: https://gitorious.org/sword-svn-mirrors/trunk I haven't been satisfied with this mirror (not proper names in git fashion, no branches, and no tags), so I have created IMHO a more proper one on https://gitorious.org/sword/sword I know there is an organization on https://github.com/crosswire which has been already used by JSword folks, but let me just say that I prefer free software hosting over proprietary ones. Also, with DVCS it doesn't matter that much which server the repository is currently hosted on, it can be transferred to github easily if the wish arises. I am certainly willing to add more collaborators to the repo or create sword-maintainers team. This repo should be automatically mirrored each day from SVN. Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC In the government of this Commonwealth, the legislative department shall never exercise the executive and judicial powers, or either of them: The executive shall never exercise the legislative and judicial powers, or either of them: The judicial shall never exercise the legislative and executive powers, or either of them: to the end it may be a government of laws and not of men. -- John Adams in the Article XXXth of the Constitution of the Commonwealth of Massachusetts ___ 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 ___ 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 -- Mark Trompell Foresight Linux Xfce Edition Cause your desktop should be freaking cool (and Xfce) ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On 08/16/2013 11:50 AM, Mark Trompell wrote: I guess it's about githubs source code isn't entirely free software. To be exact, I am more concerned about my ability to install my own installation of the gitorious. It is my paranoia of having my data under the control (or at least being able to access it whenever I want). I don't use GMail, GCAlendar, etc. in preference to my own hosted Zarafa on my own server. But yes, generally, it was about free as beer v. free as in freedom. Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC This conversation can serve no purpose anymore. Good bye. -- HAL9000 in 2001: Space Odyssea signature.asc Description: OpenPGP digital signature ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On Fri, Aug 16, 2013 at 11:33 AM, Matěj Cepl mc...@redhat.com wrote: On 08/16/2013 11:50 AM, Mark Trompell wrote: I guess it's about githubs source code isn't entirely free software. To be exact, I am more concerned about my ability to install my own installation of the gitorious. It is my paranoia of having my data under the control (or at least being able to access it whenever I want). I don't use GMail, GCAlendar, etc. in preference to my own hosted Zarafa on my own server. Well thanks to the magic of git, you wouldn't lose anything except your log in functionality if github ever goes away. Oh, you'd also lose information about who branched your code, etc, but you wouldn't know that with gitorious either. The only thing you'd lose is that pretty wrapper around it. --Greg ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On 12/17/2012 09:13 PM, Jaak Ristioja wrote: I created a new git mirror of the SVN trunk of Sword at gitorious: Gitorious web page: https://gitorious.org/sword-svn-mirrors/trunk I haven't been satisfied with this mirror (not proper names in git fashion, no branches, and no tags), so I have created IMHO a more proper one on https://gitorious.org/sword/sword I know there is an organization on https://github.com/crosswire which has been already used by JSword folks, but let me just say that I prefer free software hosting over proprietary ones. Also, with DVCS it doesn't matter that much which server the repository is currently hosted on, it can be transferred to github easily if the wish arises. I am certainly willing to add more collaborators to the repo or create sword-maintainers team. This repo should be automatically mirrored each day from SVN. Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC In the government of this Commonwealth, the legislative department shall never exercise the executive and judicial powers, or either of them: The executive shall never exercise the legislative and judicial powers, or either of them: The judicial shall never exercise the legislative and executive powers, or either of them: to the end it may be a government of laws and not of men. -- John Adams in the Article XXXth of the Constitution of the Commonwealth of Massachusetts ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On Wed, Aug 14, 2013 at 9:52 AM, Matěj Cepl mc...@redhat.com wrote: On 12/17/2012 09:13 PM, Jaak Ristioja wrote: I created a new git mirror of the SVN trunk of Sword at gitorious: Gitorious web page: https://gitorious.org/sword-svn-mirrors/trunk I haven't been satisfied with this mirror (not proper names in git fashion, no branches, and no tags), so I have created IMHO a more proper one on https://gitorious.org/sword/sword Since SWORD currently does not have any branches that are actively maintained, that seems a moot point. I'm curious what you mean by not proper names in git fashion. I know there is an organization on https://github.com/crosswire which has been already used by JSword folks, but let me just say that I prefer free software hosting over proprietary ones. Also, with DVCS it doesn't matter that much which server the repository is currently hosted on, it can be transferred to github easily if the wish arises. I'm unsure what your criticism of github is, but https://github.com/github if you want to see the piles and piles of code github has available for the community. Overall it seems as though gitorious and github are basically the same. Six of one, half-dozen of the other. One thing a github repository gains (not sure about gitorious?) is that it's natively bilingual. If someone wants to clone my Sword repository with git they can hit up https://github.com/greg-hellings/sword.git But if they prefer Subversion they can hit https://github.com/greg-hellings/sword/trunk or https://github.com/greg-hellings/sword/branches/v1.7-bugfix Then they don't have to be bothered with git but can still access my work and branches. --Greg ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.12.2012 00:48, Troy A. Griffitts wrote: Hi Jaak. Of course I would discourage confusing potential developers with an unofficial fork of the SWORD library on gitorious. I agree that this would cause confusion. It were better to avoid. That's why I started this outrageous thread. :) But I'm confused by your comments. My apologies if I have any outstanding commits in my queue from you which I haven't committed. Do I? Not that I'm aware of. However, I've seen several important issues on sword-devel mailing list, one or two of which I've filed, end up being discussed but never leading to actual solutions. My complaint against the Bibletime code is that they inefficiently use the SWORD engine by trying to wrap everything in their own classes which even I have trouble understanding the intent. SWORD was made to be used in a frontend, and we make it pretty easy to use. I use it directly in the frontends and projects I have written and cater it to real frontend needs. Bibletime, for the long life of the project, has said they want to maintain this wrapper layer around SWORD such that they can replace SWORD with an alternate backend in the future. This has never happened, and I the Bibletime frontend code which has been 'protected' from SWORD has itself been rewritten many times, as far as I can see from the mailing list. And though we've tried to encourage collaboration for years, we have seen next to zero contributions to SWORD from any of the Bibletime team (no offence to Greg and others who contribute to many projects and who do contribute to SWORD). I have tried to get participation, but I usually only get complaints and arrogant calls for a complete rewrite from developers who don't even understand what's under the hood. As developers of a front-end, we are keen to have new features added. We're displaying the module texts as HTML. But not just as Sword passes them to us, but we would like something more. We want to transform those Sword outputs, e.g. add some interactive features etc etc. This requires some sort of additional processing. Developing such processing is complicated, because we're not absolutely sure about the format of the output Sword produces. Sometimes it has not been valid and we've seen strange markup being output to the user which he or she should not see. Working around such things has been a pain. Sword lacking a full formal specialization (e.g. BNF grammar) of the output in its documentation is a problem for us. Of course I don't understand what's under the hood. I've been studying the code and any documentation I've found, but still haven't figured it out. I personally am old school and haven't acclimated to git. I've used it for work projects and can get around. There are many things I don't like, but git proponents seem to love it. I firmly don't believe that our source control system is the hindrance to contribution. We have a fairly high bar for contribution because so many projects use our engine. In my experience, most open source developers don't take code criticism well and are not willing to submit to an authority when they are volunteering their time-- which is their prerogative. We don't allow our code to simply 'churn' because people want change it. We require a real use case and defence for changes, to protect our frontend developers from having to change their code, and our interface has remained fairly stable over the year because of this. Sword could apply a workflow which would not 'churn' the code, e.g. with gatekeepers who optionally merge changes from others repository clones to the main repository. See http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows http://thkoch2001.github.com/whygitisbetter/#any-workflow Having said this, I do have a couple submissions (e.g., inter-versification mapping framework) which I have not been diligent to confirm and commit. But unless this is your specific complaint, I'm not quite sure why the rebellious nature of your email, instead of a friendly conversation about how to get your developed new feature into the engine. I'd be happy to work with you on anything you've developed. First of all, being rebellious is not my intent. I just want to push the project for some good synergy. In reply to my first post I have already received personal emails with requests to actually start handling a fork, do a release from it ASAP, fix the interfaces and compiler warnings. I don't want to fork. I don't think others want to split the project either. But we need fixes to applied faster, bugfix releases to be made earlier etc. Me and other volunteers are willing to do some work for this. We're asking for Sword to meet us halfway. I work as a C/C++ engineer, I have a MSc in Computer Science, specializing in programming language theory. At work, I refactor a lot of code, I read the ANSI C and C++03/C++11
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.12.2012 07:11, Troy A. Griffitts wrote: 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. How about allowing any custom transports layers to used via the library interface? 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. My original post was partly because of the discontent I've seen in the developer community, and only partly because of my own frustration. But I still think I needed to pop these things up for discussion. 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. For each major release we at BibleTime start a new stable branch. For example, 2.9.0 gets a stable-2.9 branch. Meanwhile development continues on the master branch. Occasionally commits from the master branch and other fixes are backported to the stable branch. Versions 2.9.1, 2.9.2 etc only get released from that branch. This keeps stable stable and the volatile volatile. 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. I never meant to insult You in any way. If You feel that way, I apologize for my poor choice of words and the deficient amount of time I have been able to pour into writing these letters. I and others have just expressed our problems and feelings of frustration with the current state of things and our eagerness for certain changes (to ease our frustration and fix some problems). My first letter in this thread I tried to enlighten the audience about what is going on at BibleTime concerning Sword. I admit that it was somewhat provocative (highlighting potential threats to the current project). But it was to provoke some kind of discussion, a process of healing, and not a quarrel. In case I have failed in archiving this, I apologize. We must all keep in mind that we share common goals. We are discussing these things to try initiate processes to help our projects and the community. There are issues and I pray that God would help us to solve these in His love and understanding and in a brotherly fashion. Sincerely, Jaak -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQgcBAEBAgAGBQJQ0CuLAAoJEEqsYmEt1rCORG0//Rgwd/1jmU56TzhPBS98T4FI Gq4td6GtkWSlUwU3TdnjnVRoZM5XgJJAobVnKjaAK/tFMqcoZIXJHoyHBlXTTaie D4rHTlIjArJK3jxgs+4X3GeD5RY4tXCgthhZdycy36kwUjBIL48qwhw+gJkOJdg6 jyytoKR/o38PwQCBgJI5fQyOinqnYGQFXcLS0ylObMfCI5e79wIG45ksVQXbxZM9 O8BIxJahmFZjmXaf9XX9gG7fmyJvZ3BRp+Cv8Ex20UkXL8X9Xfi2jBrGUFQCpyAH b0KP18rAn+53fmcl2GVwcVxLbrX/9RKs2/7wPRHaURValjaxAZtNsVqgVpivNv4P tqxFZlsaHkcRa9gFJWCXccFVDVUXl5LbgVyOJdaN+MxI6vfkWggzpiBSUvNFZ264 MFJTWxTEv8K4kKrFLStc48MOPxh6KpUWab5mCaNaO0nX+BQGwR9pM0TqiyLOnJN6 XqUtwNBwHr31hDXKFOMZ8eUa9iFEY/HRyzTB3XfudV/11Eilo0KIqAQqAGoU+MG7 IukNlSWnwXDP8gghs+fTPnWR7CL08F2vtaNRDkBRyDyxgbeUGtxuZzgz5+IJvwUS YhRUq37ikT9PSxm0TywXUPqRu/X5+KTVaaq/qQSpbhjmEm8hbVLOAowjec0jG0k1 I6YI0TS2eB2/zyLGdeZAzFdR6Uv/K82kAmF2LD9sXpJaGYg+VhCzT9dqMhY7MAP+ C6doydNFqXsxIbgWKb1FrMoZOuvLttWXZpmRFANWDDwKWjZaNgy/XhHkiZkVwPVr UQD8oPQRbs4dTbmM/5kymO5gzGK7iJdA3eBaj7xbVx87WEcpyqCTSjsdITcseRhl QqtkyXMfrlHNcGCmsQetstxrBkXzJhpN0FFSoQ5iOaUBnin46RyNaLFCoBlfbEf3 IyJYs9DfzQ8YZxlbr1bCo4pyJg+alPCu8NIqTnTNOVg8sdX9C4wk6Dtx863iKtvg VOeer4L8C6oqmK0do0S0/R/owJ5Tm4+USkxwbuGXHDV8NH7aUP3MnchzMeIQNoY/ lSX+eE2yLRZvxd9dwF/Zee+jSB/TUhNDCCBP+Ue0+/CXWiyX2lVCU5XCs5alfNmU LFC+Iyn9O2vBbaNDcTg1+TBxCRbsT/FjIE5kWSHtG8t6MYhdoa0oWNibPgG6UznX /EhHkQHP8kwyYgGxh0yxAsDD0plcm8dbPXfAx096c9z5scWlcv/MCAEgeAd9phN1 aDxbsEJL0SlN0vTZ3fEGVIoZiJmiREYTaIMOpYlvHsM+XV93D3YDmpBwknXf7wed jOnXHzMFT4fHV1BgV54UvqUmDnYsuJUjnbS81EWC2QFyiTQ5IC/3kYWkKIhScUeb wZEMzyDhNi+uycdI7cu0FWWGEyVu/lqrzyGrJvQx6gOwdOF7G/35g4eeVtWbGcHB +9cPr8OrT7dOKeHruKped4zOvVnf9FQJgCCe9oNSQeubnJ65lnNZd3QiT0ZH67Ts
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On 18/12/12 01:10, Greg Hellings wrote: Sword's SVN (I'm guessing from gcc 4.7 patches?) but BibleTime can only reliably track released versions for the sake of packaging systems. Are you sure about this? There are many many packages in Fedora (and I believe Debian will be in the same situation) which are from unreleased VCS checkout. Not that it would matter for whole discussion, but just suggesting workaround for your actual situation. were mentioned (but Linux packagers will absolute forbid that); once That's just plainly not true if that should read all Linux packagers ... see for example https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages (I don't know Debian policy enough anymore, so I cannot point you to the URL). The world is just not so neat anymore, so large distribution couldn't survive insisting on having only releases with nice tags. Yes, many packagers (me included) hugely prefer having released tarballs, but it does not mean there is no way at all. Also, yes, it is hugely preferable to have as few as possible patches in the distribution packages, but it is not like the end of the world if there are some. Especially patch which resolves FTBFS on the particular platform is quite common. All that saying, yes, where is the list of blockers of the new release? Having said this, I do have a couple submissions (e.g., inter-versification mapping framework) which I have not been diligent to confirm and commit. Couldn't they just wait for the next release, if it was the way how to avoid a fork? Although you seem happy to work with SVN, many (I do not say 'most' because I don't know any hard statistics) open source developers no longer are. I would call a BS here. If they don't know how to use git svn, they should read its manpage (or google for HOWTOs; and that's from me, who uses git exclusively for all my projects, even though I have to use some additional conversions). And of course, what stops anybody from creating and maintaining https://github.com/crosswire/sword as the official GIT mirror and the environment where the next release could be finished? Yes, that would be fork, but a friendly fork expecting to be merged back to the main repository (or starting to be a new repository). And there is always my https://gitorious.org/sword/sword (synced with SVN more or less daily, when the updating doesn't fail and I have running computer during the day). I am ready to accept pull requests and maintain the next branch which would be eventually merged into mainstream repository (whatever it will be, SVN or git). If anybody doesn't know how to use git, I am willing to help in answering any questions (after your read http://www.progit.org/) here or on IRC/XMPP. We went through it with JSword and they seem to be humming pretty happily now. I've seen multiple times on IRC along with more than one question of whether the project is still active at all, citing as specific reasons (1) no new releases in a long time - it has been two years and two months since the last release, This is the problem ... release early, release often. (2) no official presence on github There was free software before github and the main advantage of git is that one is not dependent on any central repository. have come in multiple times to ask about one of them. There are also occasional requests for modern translations, among them the NASB, which no action has been seen on. The problem of NASB is not that it is modern, AFAIK, but that it is commercial and they don't allow free distribution. What can we do about that? Meanwhile we have ESV, which is very close to NASB in its target audience and it is considered very good translation in the same rank of quality as the best of them. Much bigger problem IMHO is that we don’t have a good equivalent of NIV (general mainstream Bible for everybody) and NLT for beginners. But there isn't much we can do about it, I am afraid aside from prayers. Yes, there are people who will always want to fork and do things their way - if, some day, someone gets up the energy and time to do that, there's nothing to stop them from scratching that itch. But I think you'd see the majority of the current complaint go away with a release schedule that is established and adhered to. Even if it's a long cycle and not the 6-month cycle of Fedora and Ubuntu, if we knew that a release was coming and when it was, then both BibleTime and Xiphos could see updates and know when a feature - like XHTML - would be available. There is nothing wrong with even shorter release cycles than six months ... release early, release often, release whenever there is something to be released, and maintain your trunk/master so that it can be released anytime. Just saying Blessings and Merry Christmas, Matěj signature.asc Description: OpenPGP digital signature ___ sword-devel mailing list: sword-devel@crosswire.org
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On 18/12/12 06:11, Troy A. Griffitts wrote: Regarding release schedules, our private email conversation, Karl, were productive and I thought I had outlined a plan to you. I accept the http://producingoss.com/en/setting-tone.html#avoid-private-discussions Please. Matěj ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
Dear Jaak, I appreciate the heart of your last two emails. Collaboration has always been at the core of our purpose for the existence of CrossWire and I would love nothing more than to share together in work with you. Before I answer specifics in your emails, may I please suggest that you try to enter our developer community by seeing a very small and insignificant need, discuss a fix and receiving feedback on the best way to go about that fix, and then submit a patch. I think you will find that we are eager to accept quality contributions to the code and would be excited to have an additional contributor. I would be overjoyed to have someone help. On 12/18/2012 01:03 AM, Jaak Ristioja wrote: As developers of a front-end, we are keen to have new features added. Yes, me too! This is where to discuss them. We're displaying the module texts as HTML. But not just as Sword passes them to us, but we would like something more. We want to transform those Sword outputs, e.g. add some interactive features etc etc. This requires some sort of additional processing. Developing such processing is complicated, because we're not absolutely sure about the format of the output Sword produces. Sometimes it has not been valid and we've seen strange markup being output to the user which he or she should not see. Working around such things has been a pain. Sword lacking a full formal specialization (e.g. BNF grammar) of the output in its documentation is a problem for us. Let me start by saying that the process you describe here is challenging: taking complex tagged texts in various markup formats, submitted by a diverse group of content authors, and transforming each of these into something valid and consistent. This is our goal, and the grail of the engine. All I can say is that, as we encounter new and creative methods of markup, we do our best to normalize these into something sane and try our best to balance between: 1) preserving intended features of the author, with 2) normalizing as much as possible to conform the output to some common markup I get slammed on both sides. Content authors and their representatives here want me to touch as little as possible. Frontend developers cry for a consistent output. Of course I don't understand what's under the hood. I've been studying the code and any documentation I've found, but still haven't figured it out. I'm happy to help if you have questions. If you'd like to contribute to ease the pain for the next engineer, as you go through this learning process, please please please diagram or document concepts as you learn. I would love for a contributor to fill this void. Sword could apply a workflow which would not 'churn' the code, e.g. with gatekeepers who optionally merge changes from others repository clones to the main repository. See http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows http://thkoch2001.github.com/whygitisbetter/#any-workflow We have a well documented development workflow we advertise and hold as our goal. It is the very first link (Development Process) on our developer page on the The SWORD Project website: http://crosswire.org/sword/develop It is far from reality and you can see from the wording (e.g., CVS) that the tools have changed, but the *intended* workflow is still our desire. First of all, being rebellious is not my intent. Thank you. Your subsequent emails were very helpful to diffuse this impression. I just want to push the project for some good synergy. In reply to my first post I have already received personal emails with requests to actually start handling a fork, do a release from it ASAP I would love for someone to hold the release manager pumpkin, to schedule dates and herd developers to get their fixes in before a deadline, call for testing periods, and then package up official releases. Maybe someone out there loves doing this. I don't. I'm bad at it. Great place for someone to step in and make an immediate impact. , fix the interfaces We've been slowly normalizing interfaces toward a 2.0 release for years now, but this involves mostly naming conventions. There are always improvements we could do, but please realize any change to an interface impacts many people. Without a diatribe on proper interface design, is there one single small interface 'bug' you've specifically had trouble with, which you honestly feel warrants your time and energy to suggest a change, and would warrant many client projects' change to adapt to that interface change? If so, I'm happy to entertain a constructive conversation about one specific problem you've had and your suggested interface fix. Please start a new thread, if so. and compiler warnings. We've had arguments about the level of catering we will do for compiler warnings. Different distros turn up checks and warnings to different levels. The current place we are at
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
Hi Jaak, On Tue, Dec 18, 2012 at 7:03 PM, Jaak Ristioja j...@ristioja.ee wrote: ... I work as a C/C++ engineer, I have a MSc in Computer Science, specializing in programming language theory. At work, I refactor a lot of code, I read the ANSI C and C++03/C++11 standards (drafts) almost daily. I'd like to extensively refactor and optimize your code. Are you sure Sword could handle my stream of patches by email? As a front-end developer I'd be concerned about this. I have been involved in a number of big rewrites over the years, and while they always seem good at the start I cannot remember one that actually achieved what was meant to be achieved (except one where the original code didn't work at all, so the rewrite was basically a from scratch implementation). It is not clear to me whether the changes you suggest would substantially change the interfaces. If they did, I would be even more concerned, as it means everyone else (probably not familiar with the change) has to play catch up, with unknown impact on performance, cross-compiler compatibility, ... If there are significant design changes, it seems to me that the affected party at the design level has to extend beyond Troy to all frontend developers interested, prejudiced or conservative. Again, speaking in generalisations, it is very easy to think that my code is easy to understand and your code is hard to understand. I know Troy has expressed difficulty understanding BibleTime code, and I personally would probably have some difficulty understanding both SWORD code and BibleTime code. My main concern would be that a large number of changes come that make perfect sense to you or to BibleTime, but are as bad or worse for other front ends. This is not necessarily an argument for no change - but it is definitely an argument for extreme skepticism about changes to improve code. I have seen many examples that work, and many that don't. Jon ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On 18 December 2012 13:28, Matěj Cepl mc...@redhat.com wrote: On 18/12/12 01:10, Greg Hellings wrote: were mentioned (but Linux packagers will absolute forbid that); once That's just plainly not true if that should read all Linux packagers ... see for example https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages (I don't know Debian policy enough anymore, so I cannot point you to the URL). The world is just not so neat anymore, so large distribution couldn't survive insisting on having only releases with nice tags. Debian policy does support for snapshot packaging, where when appropriate http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1 But stable longer-term supported release are more appropriate for Debian as a rule of thumb. Yes, many packagers (me included) hugely prefer having released tarballs, but it does not mean there is no way at all. But I package stable releases + selective patches. Which goes both ways. I had to disable binding for wheezy release, due to FTBFS with new gcc no patches available to resolve the issue. Now wheezy is frozen, and new features are not accepted. Oh well, bindings didn't make it into previous release will not make it into the current one either. Also, yes, it is hugely preferable to have as few as possible patches in the distribution packages, but it is not like the end of the world if there are some. Especially patch which resolves FTBFS on the particular platform is quite common. From time to time, I do have to apply debian-specific integration patches, which is fine. On the other hand, multiple releases of sword have not been accepting debian patches to check for status/error codes from api calls All that saying, yes, where is the list of blockers of the new release? I would like to see such a list as well. Regards, Dmitrijs. ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
Can I suggest we put this on github under the crosswire organisation? We already have JSword there... github.com/crosswire Chris On 17 December 2012 20:13, Jaak Ristioja j...@ristioja.ee wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! The Mirror == I created a new git mirror of the SVN trunk of Sword at gitorious: Gitorious web page: https://gitorious.org/sword-svn-mirrors/trunk Git URLs: https://git.gitorious.org/sword-svn-mirrors/trunk.git git://gitorious.org/sword-svn-mirrors/trunk.git g...@gitorious.org:sword-svn-mirrors/trunk.git Why? In short: there's a possibility that there might arise forks. The BibleTime team has long been contemplating on how to relate to various issues with Sword and its development, which has somewhat hindered the development of BibleTime, fixing or working around bugs dependant on Sword etc. Up to this point, we have discussed 1) writing an alternative backend for BibleTime to replace Sword, 2) writing a better wrapper around Sword which would hide its deficiencies, 3) a combination of 1) and 2) and allow BibleTime to use multiple backends, 4) forking Sword as a separate project, and 5) embedding a forked version of Sword SVN in the source code of BibleTime which would be partly kept up-to-date with the original project. At this moment we have not yet reached any decision whatsover, but these discussions have become rather frequent. Personally, as a developer and the current lead of the BibleTime project, I'm not satisfied with the code quality of Sword, and find lacking the documentation of Sword interfaces and file formats. In addition, as an outsider I have long found it difficult to do anything about it, partly because of the centralized version control system used by Sword (SVN), and partly because the lack of explicit guidelines for new developers (how do I start, get my proposed fixes and changes applied etc). I just wanted to clarify what has been under discussion @ BibleTime during the previous years and what we feel we're experiencing towards using Sword. I'm not offering any silver bullets, except that for one thing I urge the Sword project to release a new version of Sword soon. However, personally, I'd place my bets on recruiting new developers for the Sword library (and git). Blessings (and please don't ban me :), Jaak Ristioja The BibleTime team -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQgcBAEBAgAGBQJQz3z3AAoJEEqsYmEt1rCONAhAAJK7kbcEr2U0W2pblMxHvsaz yEwFM3NZr1pe72SZag4JVLpH1wWpWo1xDU4gkQYgD3x5hlKiS+wmXXSCMVxZ6clT s47mHiyMMaVRCd2LEf6L5wCaBeO45MTcvBEtE1WeVdKuzQ1u1poEJ8XV0hiuU/AH lJBLbMXFotGlPz7s/ILVqJsyLjyveEQRB9xcL7+MKOd0BgayknYfNRpjBCvb7tCn dg+LqezOqKDJQD2RAO1cz+dEyt0A6H6wQNYriIqF2hNCT4moAYAPvWfFc3IQrP0G NYrJpUQIUawAeJHjRHlrq5bT9CbKqvyBGZM4m3T0uRynIWVO3hEi+V4nDkJO6IOk 6ZdwZ1EBRKniGcurKDISol4uNySiOkDrasn5bJP4Re0ekF+oyOwrlC+LyATJDv88 msA0j3OzhcFr/4/+GGaMinNsjEK7w+ANIzyCkiLSHWrs17bR6H1e/U9btyetHdW0 5O/ak4kHfbx88fea03zflAGrvOl2gWEQfEwR/o+08oJpjlw8MkNjDo6iUq6cj6/P aBi8+B7r+YyPrF7ow1d22/AkjYfFXq/WOoXNFkHi1fYGR4XvahPBUvZGHrLTxGYf 89uzvi3paO5EopSjlb7k+8dmceSNzYFAuXkIqNSiLfWQ7ZzkTirw6BqmXYZdeq5M yGeGZvzkaYXJNnGA+xKr1TcXuTXfxrQ2fZG/7Ck/V/TXMHUUsLSrchU6Ph39VKj8 8JetRz9gSX3QeuEV8uBCS/pWgRIC7VM+myNlgtH3XfPBPuw65iuO0olkd5u7Doki u4sqBWU7wMYh7bK2JwLDGN12N9dyyn+XPQZJwj9hvSMi4jlZZqG2QCCPrTsfjdGS kTreb8aX3xNVKsEvU4tVKEFN1TzW5Gv834EugTMHM3Eb6I385Phr/2KTb8TewDC3 hAbr7Ep4HuAHGiQPJXiIuFwAYDdTsa12gsonghKF60iTlVP0U197VYhr6h48UiW4 9eoyNlToMIJZOCIuXiflhAkbr+YRvHzY0tmADlcQLUUISq7739r9QD9AzZsCPJ3e bEPGj/cp3CELy7oIR3s0t891MGMZBrIA7ecoCkfzyncFLVQ5Pon5Lo0aXwE7qWdW ODxtxHSJY8FrFN+hXMTMCX622yENSlN9dyzqgCVs+MdMC6fS7uEI2SZmAyVKJs7S u86F3KyVwlAYDeHWd/Aci46CKQ4sKoEJDPpBawhlnlQi1mNau0Ls4qF/9IM6YPoP eOmvKQraCcaLBtvZUoWSrQ/bWSNUn3jGzA/9njucqwBpzTYspie/q0WiKWM2hcp+ +NnL5FwiLPdMGPtjskXrQp7j+OfUOm5pOILpCCjEmlJtCBVF1SdvyNcgTv7JpuQS QAJm0UCDGjhboD4MG37m9xJs7g0D1/x/aimsjkptkzWQ6u3MvtfSFMx3zGBlCK6A lJQpU4x7m7PAF/+g4Dm1iFGmvad3aIY1C94+Yp0+QDZbZzZgck/d8JHEb/1peO88 8FqQEygvVqT+kh5TobdEK2r8A/4y6ef9SBBZtCYXnYyach6mRzFIkP9ffRFvpnLg YGETfXj3zV+ZzBX5KlVq8pbycPcskp1wMOBfQFdpDVXfVUbrlpYoZ3m0jK37EZfx AyVYmiQaapTpJYhDpKezeD7+lrgV4nYw7I3teK8zh4hOJyOuWBEeRHufh9C9bgWK 3edSXTl1dzf6y0CYXS/zRkeY4On9Go3mFNV9ZVUYn3miTtIAb67Unaz9Y17Uw800 zFku0OQhgj5irenxEHG3pVP/9K5GA1UaIW7RmMDa+/dId764oLUTJo9deegMaSV1 uy9GDyupMkm8ZLmTzvrqNfEa5/6MIXLzJ/H+E/5YnQ45UD+T8s/PmAl5IN0YC9Yd 7lprKAOpO7UbOHHoE45yA/YhFyn04kiGlfe64MPwepdg4GHSTKCnOeESUhyk4sno Ry/ty/REHQ7LZ8cojcikkVIGekffqnw0dC532jmv7ILlaOBK0i20+/B6BWEGQlkg 9yx+deIX4fYhBkfCZU/8R2y5X1iDTKIcboMqnDJv/4Ki+ndklMrGI1HL4oFwjmF3 aG34V5Bs60gPlJO9CJVb2PEX6r3QmvLctQ85u2ATIh65ennMzc4J6mSQ/Y9WnQvT gVt3UXD1qLCscujr51wNBZ26CJ2fQ2mKdXtzODBO2rlrVZs4UDZx7IDnRr3ASrTY c5o2KUDWx7YTA4XwHas9Fk2bFBEJ3Luf21PlztpbVa/9oaFEGO7rzA9h1bP3VMbZ M1Vy0yxH9f0Ifat2APAzF/YTE2ZUEppkQsnCfyshN9DlOg2wBhkhLUdn6bRyp8W4
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
The use of SVN is increasingly viewed by opensource developers as an indication of the poor health of an opensource project. The traffic that I have seen here indicates that it is not the case for this project but it doesn't change the fact that it's use will warn potential developers away. On Tue, Dec 18, 2012 at 9:47 AM, Chris Burrell ch...@burrell.me.uk wrote: Can I suggest we put this on github under the crosswire organisation? We already have JSword there... github.com/crosswire Chris On 17 December 2012 20:13, Jaak Ristioja j...@ristioja.ee wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! The Mirror == I created a new git mirror of the SVN trunk of Sword at gitorious: Gitorious web page: https://gitorious.org/sword-svn-mirrors/trunk Git URLs: https://git.gitorious.org/sword-svn-mirrors/trunk.git git://gitorious.org/sword-svn-mirrors/trunk.git g...@gitorious.org:sword-svn-mirrors/trunk.git Why? In short: there's a possibility that there might arise forks. The BibleTime team has long been contemplating on how to relate to various issues with Sword and its development, which has somewhat hindered the development of BibleTime, fixing or working around bugs dependant on Sword etc. Up to this point, we have discussed 1) writing an alternative backend for BibleTime to replace Sword, 2) writing a better wrapper around Sword which would hide its deficiencies, 3) a combination of 1) and 2) and allow BibleTime to use multiple backends, 4) forking Sword as a separate project, and 5) embedding a forked version of Sword SVN in the source code of BibleTime which would be partly kept up-to-date with the original project. At this moment we have not yet reached any decision whatsover, but these discussions have become rather frequent. Personally, as a developer and the current lead of the BibleTime project, I'm not satisfied with the code quality of Sword, and find lacking the documentation of Sword interfaces and file formats. In addition, as an outsider I have long found it difficult to do anything about it, partly because of the centralized version control system used by Sword (SVN), and partly because the lack of explicit guidelines for new developers (how do I start, get my proposed fixes and changes applied etc). I just wanted to clarify what has been under discussion @ BibleTime during the previous years and what we feel we're experiencing towards using Sword. I'm not offering any silver bullets, except that for one thing I urge the Sword project to release a new version of Sword soon. However, personally, I'd place my bets on recruiting new developers for the Sword library (and git). Blessings (and please don't ban me :), Jaak Ristioja The BibleTime team -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQgcBAEBAgAGBQJQz3z3AAoJEEqsYmEt1rCONAhAAJK7kbcEr2U0W2pblMxHvsaz yEwFM3NZr1pe72SZag4JVLpH1wWpWo1xDU4gkQYgD3x5hlKiS+wmXXSCMVxZ6clT s47mHiyMMaVRCd2LEf6L5wCaBeO45MTcvBEtE1WeVdKuzQ1u1poEJ8XV0hiuU/AH lJBLbMXFotGlPz7s/ILVqJsyLjyveEQRB9xcL7+MKOd0BgayknYfNRpjBCvb7tCn dg+LqezOqKDJQD2RAO1cz+dEyt0A6H6wQNYriIqF2hNCT4moAYAPvWfFc3IQrP0G NYrJpUQIUawAeJHjRHlrq5bT9CbKqvyBGZM4m3T0uRynIWVO3hEi+V4nDkJO6IOk 6ZdwZ1EBRKniGcurKDISol4uNySiOkDrasn5bJP4Re0ekF+oyOwrlC+LyATJDv88 msA0j3OzhcFr/4/+GGaMinNsjEK7w+ANIzyCkiLSHWrs17bR6H1e/U9btyetHdW0 5O/ak4kHfbx88fea03zflAGrvOl2gWEQfEwR/o+08oJpjlw8MkNjDo6iUq6cj6/P aBi8+B7r+YyPrF7ow1d22/AkjYfFXq/WOoXNFkHi1fYGR4XvahPBUvZGHrLTxGYf 89uzvi3paO5EopSjlb7k+8dmceSNzYFAuXkIqNSiLfWQ7ZzkTirw6BqmXYZdeq5M yGeGZvzkaYXJNnGA+xKr1TcXuTXfxrQ2fZG/7Ck/V/TXMHUUsLSrchU6Ph39VKj8 8JetRz9gSX3QeuEV8uBCS/pWgRIC7VM+myNlgtH3XfPBPuw65iuO0olkd5u7Doki u4sqBWU7wMYh7bK2JwLDGN12N9dyyn+XPQZJwj9hvSMi4jlZZqG2QCCPrTsfjdGS kTreb8aX3xNVKsEvU4tVKEFN1TzW5Gv834EugTMHM3Eb6I385Phr/2KTb8TewDC3 hAbr7Ep4HuAHGiQPJXiIuFwAYDdTsa12gsonghKF60iTlVP0U197VYhr6h48UiW4 9eoyNlToMIJZOCIuXiflhAkbr+YRvHzY0tmADlcQLUUISq7739r9QD9AzZsCPJ3e bEPGj/cp3CELy7oIR3s0t891MGMZBrIA7ecoCkfzyncFLVQ5Pon5Lo0aXwE7qWdW ODxtxHSJY8FrFN+hXMTMCX622yENSlN9dyzqgCVs+MdMC6fS7uEI2SZmAyVKJs7S u86F3KyVwlAYDeHWd/Aci46CKQ4sKoEJDPpBawhlnlQi1mNau0Ls4qF/9IM6YPoP eOmvKQraCcaLBtvZUoWSrQ/bWSNUn3jGzA/9njucqwBpzTYspie/q0WiKWM2hcp+ +NnL5FwiLPdMGPtjskXrQp7j+OfUOm5pOILpCCjEmlJtCBVF1SdvyNcgTv7JpuQS QAJm0UCDGjhboD4MG37m9xJs7g0D1/x/aimsjkptkzWQ6u3MvtfSFMx3zGBlCK6A lJQpU4x7m7PAF/+g4Dm1iFGmvad3aIY1C94+Yp0+QDZbZzZgck/d8JHEb/1peO88 8FqQEygvVqT+kh5TobdEK2r8A/4y6ef9SBBZtCYXnYyach6mRzFIkP9ffRFvpnLg YGETfXj3zV+ZzBX5KlVq8pbycPcskp1wMOBfQFdpDVXfVUbrlpYoZ3m0jK37EZfx AyVYmiQaapTpJYhDpKezeD7+lrgV4nYw7I3teK8zh4hOJyOuWBEeRHufh9C9bgWK 3edSXTl1dzf6y0CYXS/zRkeY4On9Go3mFNV9ZVUYn3miTtIAb67Unaz9Y17Uw800 zFku0OQhgj5irenxEHG3pVP/9K5GA1UaIW7RmMDa+/dId764oLUTJo9deegMaSV1 uy9GDyupMkm8ZLmTzvrqNfEa5/6MIXLzJ/H+E/5YnQ45UD+T8s/PmAl5IN0YC9Yd 7lprKAOpO7UbOHHoE45yA/YhFyn04kiGlfe64MPwepdg4GHSTKCnOeESUhyk4sno Ry/ty/REHQ7LZ8cojcikkVIGekffqnw0dC532jmv7ILlaOBK0i20+/B6BWEGQlkg
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
I would agree with the above with the caveat that some recent very good, very alive Apache projects are still using SVN, e.g. Hadoop, Accumulo, etc. Having said that Git makes collaborating that much easier, branches are cheap and easy, forks are easy, pulling pushing changes back from a fork is also easy. For example STEP has its own fork of JSword, so that we can fix and enhance JSword quickly and yet push changes back to the main repository without there being a hard dependency between the two operations. Chris On 17 December 2012 21:44, Daniel Hughes tramps...@gmail.com wrote: The use of SVN is increasingly viewed by opensource developers as an indication of the poor health of an opensource project. The traffic that I have seen here indicates that it is not the case for this project but it doesn't change the fact that it's use will warn potential developers away. On Tue, Dec 18, 2012 at 9:47 AM, Chris Burrell ch...@burrell.me.ukwrote: Can I suggest we put this on github under the crosswire organisation? We already have JSword there... github.com/crosswire Chris On 17 December 2012 20:13, Jaak Ristioja j...@ristioja.ee wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! The Mirror == I created a new git mirror of the SVN trunk of Sword at gitorious: Gitorious web page: https://gitorious.org/sword-svn-mirrors/trunk Git URLs: https://git.gitorious.org/sword-svn-mirrors/trunk.git git://gitorious.org/sword-svn-mirrors/trunk.git g...@gitorious.org:sword-svn-mirrors/trunk.git Why? In short: there's a possibility that there might arise forks. The BibleTime team has long been contemplating on how to relate to various issues with Sword and its development, which has somewhat hindered the development of BibleTime, fixing or working around bugs dependant on Sword etc. Up to this point, we have discussed 1) writing an alternative backend for BibleTime to replace Sword, 2) writing a better wrapper around Sword which would hide its deficiencies, 3) a combination of 1) and 2) and allow BibleTime to use multiple backends, 4) forking Sword as a separate project, and 5) embedding a forked version of Sword SVN in the source code of BibleTime which would be partly kept up-to-date with the original project. At this moment we have not yet reached any decision whatsover, but these discussions have become rather frequent. Personally, as a developer and the current lead of the BibleTime project, I'm not satisfied with the code quality of Sword, and find lacking the documentation of Sword interfaces and file formats. In addition, as an outsider I have long found it difficult to do anything about it, partly because of the centralized version control system used by Sword (SVN), and partly because the lack of explicit guidelines for new developers (how do I start, get my proposed fixes and changes applied etc). I just wanted to clarify what has been under discussion @ BibleTime during the previous years and what we feel we're experiencing towards using Sword. I'm not offering any silver bullets, except that for one thing I urge the Sword project to release a new version of Sword soon. However, personally, I'd place my bets on recruiting new developers for the Sword library (and git). Blessings (and please don't ban me :), Jaak Ristioja The BibleTime team -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQgcBAEBAgAGBQJQz3z3AAoJEEqsYmEt1rCONAhAAJK7kbcEr2U0W2pblMxHvsaz yEwFM3NZr1pe72SZag4JVLpH1wWpWo1xDU4gkQYgD3x5hlKiS+wmXXSCMVxZ6clT s47mHiyMMaVRCd2LEf6L5wCaBeO45MTcvBEtE1WeVdKuzQ1u1poEJ8XV0hiuU/AH lJBLbMXFotGlPz7s/ILVqJsyLjyveEQRB9xcL7+MKOd0BgayknYfNRpjBCvb7tCn dg+LqezOqKDJQD2RAO1cz+dEyt0A6H6wQNYriIqF2hNCT4moAYAPvWfFc3IQrP0G NYrJpUQIUawAeJHjRHlrq5bT9CbKqvyBGZM4m3T0uRynIWVO3hEi+V4nDkJO6IOk 6ZdwZ1EBRKniGcurKDISol4uNySiOkDrasn5bJP4Re0ekF+oyOwrlC+LyATJDv88 msA0j3OzhcFr/4/+GGaMinNsjEK7w+ANIzyCkiLSHWrs17bR6H1e/U9btyetHdW0 5O/ak4kHfbx88fea03zflAGrvOl2gWEQfEwR/o+08oJpjlw8MkNjDo6iUq6cj6/P aBi8+B7r+YyPrF7ow1d22/AkjYfFXq/WOoXNFkHi1fYGR4XvahPBUvZGHrLTxGYf 89uzvi3paO5EopSjlb7k+8dmceSNzYFAuXkIqNSiLfWQ7ZzkTirw6BqmXYZdeq5M yGeGZvzkaYXJNnGA+xKr1TcXuTXfxrQ2fZG/7Ck/V/TXMHUUsLSrchU6Ph39VKj8 8JetRz9gSX3QeuEV8uBCS/pWgRIC7VM+myNlgtH3XfPBPuw65iuO0olkd5u7Doki u4sqBWU7wMYh7bK2JwLDGN12N9dyyn+XPQZJwj9hvSMi4jlZZqG2QCCPrTsfjdGS kTreb8aX3xNVKsEvU4tVKEFN1TzW5Gv834EugTMHM3Eb6I385Phr/2KTb8TewDC3 hAbr7Ep4HuAHGiQPJXiIuFwAYDdTsa12gsonghKF60iTlVP0U197VYhr6h48UiW4 9eoyNlToMIJZOCIuXiflhAkbr+YRvHzY0tmADlcQLUUISq7739r9QD9AzZsCPJ3e bEPGj/cp3CELy7oIR3s0t891MGMZBrIA7ecoCkfzyncFLVQ5Pon5Lo0aXwE7qWdW ODxtxHSJY8FrFN+hXMTMCX622yENSlN9dyzqgCVs+MdMC6fS7uEI2SZmAyVKJs7S u86F3KyVwlAYDeHWd/Aci46CKQ4sKoEJDPpBawhlnlQi1mNau0Ls4qF/9IM6YPoP eOmvKQraCcaLBtvZUoWSrQ/bWSNUn3jGzA/9njucqwBpzTYspie/q0WiKWM2hcp+ +NnL5FwiLPdMGPtjskXrQp7j+OfUOm5pOILpCCjEmlJtCBVF1SdvyNcgTv7JpuQS
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
Hi Jaak. Of course I would discourage confusing potential developers with an unofficial fork of the SWORD library on gitorious. But I'm confused by your comments. My apologies if I have any outstanding commits in my queue from you which I haven't committed. Do I? My complaint against the Bibletime code is that they inefficiently use the SWORD engine by trying to wrap everything in their own classes which even I have trouble understanding the intent. SWORD was made to be used in a frontend, and we make it pretty easy to use. I use it directly in the frontends and projects I have written and cater it to real frontend needs. Bibletime, for the long life of the project, has said they want to maintain this wrapper layer around SWORD such that they can replace SWORD with an alternate backend in the future. This has never happened, and I the Bibletime frontend code which has been 'protected' from SWORD has itself been rewritten many times, as far as I can see from the mailing list. And though we've tried to encourage collaboration for years, we have seen next to zero contributions to SWORD from any of the Bibletime team (no offence to Greg and others who contribute to many projects and who do contribute to SWORD). I have tried to get participation, but I usually only get complaints and arrogant calls for a complete rewrite from developers who don't even understand what's under the hood. I personally am old school and haven't acclimated to git. I've used it for work projects and can get around. There are many things I don't like, but git proponents seem to love it. I firmly don't believe that our source control system is the hindrance to contribution. We have a fairly high bar for contribution because so many projects use our engine. In my experience, most open source developers don't take code criticism well and are not willing to submit to an authority when they are volunteering their time-- which is their prerogative. We don't allow our code to simply 'churn' because people want change it. We require a real use case and defence for changes, to protect our frontend developers from having to change their code, and our interface has remained fairly stable over the year because of this. Having said this, I do have a couple submissions (e.g., inter-versification mapping framework) which I have not been diligent to confirm and commit. But unless this is your specific complaint, I'm not quite sure why the rebellious nature of your email, instead of a friendly conversation about how to get your developed new feature into the engine. I'd be happy to work with you on anything you've developed. Just a generic defence, Troy On 12/17/2012 01:13 PM, Jaak Ristioja wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! The Mirror == I created a new git mirror of the SVN trunk of Sword at gitorious: Gitorious web page: https://gitorious.org/sword-svn-mirrors/trunk Git URLs: https://git.gitorious.org/sword-svn-mirrors/trunk.git git://gitorious.org/sword-svn-mirrors/trunk.git g...@gitorious.org:sword-svn-mirrors/trunk.git Why? In short: there's a possibility that there might arise forks. The BibleTime team has long been contemplating on how to relate to various issues with Sword and its development, which has somewhat hindered the development of BibleTime, fixing or working around bugs dependant on Sword etc. Up to this point, we have discussed 1) writing an alternative backend for BibleTime to replace Sword, 2) writing a better wrapper around Sword which would hide its deficiencies, 3) a combination of 1) and 2) and allow BibleTime to use multiple backends, 4) forking Sword as a separate project, and 5) embedding a forked version of Sword SVN in the source code of BibleTime which would be partly kept up-to-date with the original project. At this moment we have not yet reached any decision whatsover, but these discussions have become rather frequent. Personally, as a developer and the current lead of the BibleTime project, I'm not satisfied with the code quality of Sword, and find lacking the documentation of Sword interfaces and file formats. In addition, as an outsider I have long found it difficult to do anything about it, partly because of the centralized version control system used by Sword (SVN), and partly because the lack of explicit guidelines for new developers (how do I start, get my proposed fixes and changes applied etc). I just wanted to clarify what has been under discussion @ BibleTime during the previous years and what we feel we're experiencing towards using Sword. I'm not offering any silver bullets, except that for one thing I urge the Sword project to release a new version of Sword soon. However, personally, I'd place my bets on recruiting new developers for the Sword library (and git). Blessings (and please don't ban me :), Jaak Ristioja The BibleTime team -BEGIN PGP
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On Mon, Dec 17, 2012 at 4:48 PM, Troy A. Griffitts scr...@crosswire.org wrote: Hi Jaak. Of course I would discourage confusing potential developers with an unofficial fork of the SWORD library on gitorious. I have been maintaining a personal SWORD repository on github for quite some time now (github.com/greg-hellings/Sword). It hasn't seemed to cause any confusion, but I make sure that master is always identical to SWORD's official Subversion trunk branch. I mainly use it to shuttle my own branches and changes around from environment to environment and to share them with others before I make a patch against master for submission. But I'm confused by your comments. My apologies if I have any outstanding commits in my queue from you which I haven't committed. Do I? I don't know about ones from Jaak, but I haven't seen a reply from you about my SFTP patch submission (maybe I missed it?). It was a direct feature request from a user in #xiphos and I already have a patch prepared for Xiphos to support it. Our friends at Wycliffe are also very excited about it because they are unable to expose FTP and HTTP is a pain on their end and not well supported - but they are already prepared with SSH/SFTP access for their target users. My complaint against the Bibletime code is that they inefficiently use the SWORD engine by trying to wrap everything in their own classes which even I have trouble understanding the intent. SWORD was made to be used in a frontend, and we make it pretty easy to use. I use it directly in the frontends and projects I have written and cater it to real frontend needs. Bibletime, for the long life of the project, has said they want to maintain this wrapper layer around SWORD such that they can replace SWORD with an alternate backend in the future. This has never happened, and I the Bibletime frontend code which has been 'protected' from SWORD has itself been rewritten many times, as far as I can see from the mailing list. And though we've tried to encourage collaboration for years, we have seen next to zero contributions to SWORD from any of the Bibletime team (no offence to Greg and others who contribute to many projects and who do contribute to SWORD). I have tried to get participation, but I usually only get complaints and arrogant calls for a complete rewrite from developers who don't even understand what's under the hood. Perhaps a little background, which I present as objectively as I can: One of the main complaints that's been going through IRC the past 3-6 months has been lack of a new release of the engine. Back in the Spring we were gearing up for what was already a seemingly over-due release. If my memory serves, you had said we would do a beta sometime in April or May with the intention of releasing by June 1. You then had a personal emergency that caused a delay in that time schedule, but nothing has ever come since then - no comment, no response to a timeline for a new release. I'm not sure if anyone else has been christened as being allowed to cut alpha/beta/rc/final releases of the engine, but if so they didn't step up to fill the gap. Today's most recent bug that Jaak found in the engine is an incompatibility with llvm+clang that causes compile failure in that realm. This could pose an issue going forward as Apple has switched to llvm+clang for its default compiler in Snow Leopard and I believe BSD is going that direction as well. Turns out his bug is already fixed in Sword's SVN (I'm guessing from gcc 4.7 patches?) but BibleTime can only reliably track released versions for the sake of packaging systems. The discussion of the above bug, along with existing updates that are in SWORD SVN (XHTML, HTTPS, deprecated API functions) but which are not released led to some discussion in IRC about how to get reliable releases out. Suggestions of bundling SWORD SVN in the application were mentioned (but Linux packagers will absolute forbid that); once again the suggestion of making BibleTime not rely on SWORD was mentioned (a significant amount of effort would be required, but it would be possible); also entertained was forking the project and maintaining a separate project that would have no changes to the code but would just make predictable releases of the engine (but that would mean yet another thing for distros to package and for client build systems to search for as a replacement to SWORD - thus representing a huge barrier to such a fork doing any good). But at this point BibleTime has apparently fielded at least one issue related to building against SWORD's headers in a clang environment and Xiphos is committed to using the XHTML filters. Both projects are, therefore, desperate for a new release of the engine and some developers are starting to wonder aloud if forking SWORD is the only way that we'll ever see that. Even if the fork never diverges from the base in terms of code content. I personally am old school and haven't acclimated to
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
1) writing an alternative backend for BibleTime to replace Sword, sounds like a lot of work and that time could hopefully be better spent in other ways? :/ 2) writing a better wrapper around Sword which would hide its deficiencies, Both MacSword/Eloquent PocketSword use wrappers, but that's simply to wrap the C++ code with an Objective-C++ wrapper in order to get Obj-C++ goodness throughout the apps. ;) 3) a combination of 1) and 2) and allow BibleTime to use multiple backends, 4) forking Sword as a separate project, and may be a pain for others who are part of the CrossWire community? And add more confusion for would-be developers? Your own fork that you push the changes back to the official repo might be playing nicer? But that's just my 2 cents... Perhaps along the lines of 5, below? 5) embedding a forked version of Sword SVN in the source code of BibleTime which would be partly kept up-to-date with the original project. This is actually something I do with PS, but that's simply cause of not being able to have shared libraries and stuff like that on iOS, so I need to bundle libsword in the app. And so I will have a specific version of SVN in each release of PS. And this simply makes things easier for me. I try to push (email diffs to the list) appropriate changes I make back to SVN in order to have as little different between my libsword and the SVN one as possible. From what others have said, it sounds like you wouldn't be able to do this with various distros of Linux, so that would probably mean this avenue would cause additional issues? btw, PS is on BitBucket cause I ditched the SVN that PS was initially placed into once I took over the project. So it's Mercurial, but I'm not religious about my choice... :P https://bitbucket.org/niccarter/pocketsword/overview And I love the additional web tools that you can access via BitBucket/GitHub/those things... And would hopefully make things more discoverable for would-be developers? Most of the other comments that have been made in this email thread don't affect PS, due to the particular nature of iOS apps (for example, I get to release my own custom versions of libsword, basically the latest version on SVN with any fixes that are found there, including all the latest av11n headers!), but I can hear the pain that has been expressed and am praying for resolution... :) Thanks, ybic nic... :) ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
Troy A. Griffitts scr...@crosswire.org writes: I'm not quite sure why the rebellious nature of your email, instead of a friendly conversation Troy, I can summarize with a pair of excruciatingly simple, personal examples why this sort of rebellious plan comes into play. I've got no relationship to it myself (I'm not a git user yet myself and have no beef with SVN, being unconvinced of the existence of some groundswell of objection to SVN use; this discussion is the first I heard) but I understand the motivation perfectly well. The short summary answer is simple: Friendly conversations manifestly don't accomplish anything. The long detailed answer requires those mentioned examples. 1. 29 Aug 2007 (5 years, 16 weeks ago) I sent a note to sword-devel, my first in /agent provocateur/ mode, arguing for a more regular release of the engine, trying to express a firm opinion while still being supportive. At that time, 1.5.9 had been out for a year-plus and 1.5.10 had been pending much too long. I argued that the needs of BibleTime, then-GnomeSword, and the other frontends were not being properly served by the excessively long delay in a world where frontend releases were happening between 2x and 5x per year apiece. At that time, your response was to (claim to) commit to a rough 6-month release schedule for the engine. As Greg observed, this time it's been 26 months. That's 20 months too long. That's 4+ times as long as your (claimed) commitment. 2. 10 Nov 2008 (4 years, 5 weeks ago) I sent you a private note about NASB, with a couple others Bcc'd, some of whom subsequently made themselves known and a couple of whom did not. My note pointed out that, at that time, we were approaching 5 years of waiting for one measly module to come to fruition -- a module that is arguably the #2 most-requested Bible module. Yes, it's Just Another English Bible...but it's *NASB*. It had already then been in beta more than 2 years -- it was already in beta before I got involved with GnomeSword. Again, you made fervent promises to see to finishing up the NASB module (or module set, including the Heb/Grk lexicons) right away. Well...5 years then plus 4 more years now is 9 years, and the 9th anniversary of the plan or intent or mere fond hope for a NASB module to be released will come up in early January, based on original sword-devel chatter about it. The truly sad thing is that all the NASB module needs is one afternoon of serious hackery, then kick it out the door to Lockman. The Sword-using world has been waiting another 4 years for you to find one afternoon. You know of course that in just the last few days I sent you a couple, very brief private notes about the need for 1.next. Nothing combative, nothing remotely rebellious, just noting that it is impossible for me to make another Xiphos release until you make another Sword release: Driven by chatter here, I committed Xiphos to XHTML filters, which are incomplete in current release. And then, pointedly, I forwarded one IRC question, plaintively asking whether Sword ever gets updated any more. In all seriousness, what living, vibrant, active open source project goes 2+ years without a release? Given that the issue has been raised publicly now, and that your defensive reaction takes the form of criticism for being rebellious, well, Troy... Please look in a mirror. Look closely at the face you see there. This isn't rebellion. It's frustration. This isn't rejection. It's dejection. This isn't denial (of you). It's acceptance (of what you've shown us). A great many believe, on evidence, that without occasionally whacking you over the head with a calendar -- in essence, see, it's overdue again -- no Sword engine release would ever occur at all. Your priorities are very seriously detached from those of the rest of us. That many of us have had to ask, over and over and over again, over a period of many years, to please get with the program and provide the support that the rest of us need, is or ought to be testament enough that something is very wrong, and has been very wrong evidently throughout the life of Sword -- since years before I showed up, surely. You are the founder of The Sword Project, which puts you in charge of it. As its titular leader, I wish you would spend some serious time in prayer and come to a conclusion -- a real conclusion, embodying a real commitment, one way or another -- as to whether you are willing to provide such leadership, and get on with things. Please lead, follow, or get out of the way. ___ 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
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
I deserve the rebuke for the release schedule. The release schedule was not even mentioned in the email to which I responded. 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). 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 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. Troy Karl Kleinpaste k...@kleinpaste.org wrote: Troy A. Griffitts scr...@crosswire.org writes: I'm not quite sure why the rebellious nature of your email, instead of a friendly conversation Troy, I can summarize with a pair of excruciatingly simple, personal examples why this sort of rebellious plan comes into play. I've got no relationship to it myself (I'm not a git user yet myself and have no beef with SVN, being unconvinced of the existence of some groundswell of objection to SVN use; this discussion is the first I heard) but I understand the motivation perfectly well. The short summary answer is simple: Friendly conversations manifestly don't accomplish anything. The long detailed answer requires those mentioned examples. 1. 29 Aug 2007 (5 years, 16 weeks ago) I sent a note to sword-devel, my first in /agent provocateur/ mode, arguing for a more regular release of the engine, trying to express a firm opinion while still being supportive. At that time, 1.5.9 had been out for a year-plus and 1.5.10 had been pending much too long. I argued that the needs of BibleTime, then-GnomeSword, and the other frontends were not being properly served by the excessively long delay in a world where frontend releases were happening between 2x and 5x per year apiece. At that time, your response was to (claim to) commit to a rough 6-month release schedule for the engine. As Greg observed, this time it's been 26 months. That's 20 months too long. That's 4+ times as long as your (claimed) commitment. 2. 10 Nov 2008 (4 years, 5 weeks ago) I sent you a private note about NASB, with a couple others Bcc'd, some of whom subsequently made themselves known and a couple of whom did not. My note pointed out that, at that time, we were approaching 5 years of waiting for one measly module to come to fruition -- a module that is arguably the #2 most-requested Bible module. Yes, it's Just Another English Bible...but it's *NASB*. It had already then been in beta more than 2 years -- it was already in beta before I got involved with GnomeSword. Again, you made fervent promises to see to finishing up the NASB module (or module set, including the Heb/Grk lexicons) right away. Well...5 years then plus 4 more years now is 9 years, and the 9th anniversary of the plan or intent or mere fond hope for a NASB module to be released will come up in early January, based on original sword-devel chatter about it. The truly sad thing is that all the NASB module needs is one afternoon of serious hackery, then kick it out the door to Lockman. The Sword-using world has been waiting another 4 years for you to find one afternoon. You know of course that in just the last few days I sent you a couple, very brief private notes about the need for 1.next. Nothing combative, nothing remotely rebellious, just noting that it is impossible for me to make another Xiphos release until you make another Sword release: Driven by chatter here, I committed Xiphos to XHTML filters, which are incomplete in current release. And then, pointedly, I forwarded one IRC question, plaintively asking
Re: [sword-devel] New public git mirror of Sword SVN trunk and why
On 17/12/12 21:13, Jaak Ristioja wrote: The Mirror == I created a new git mirror of the SVN trunk of Sword at gitorious: Gitorious web page: https://gitorious.org/sword-svn-mirrors/trunk Why don't you use https://gitorious.org/sword? I keep the project alive just for this purpose ... and I am willing to hand it over to anybody who will keep there a mirror on his own. Matěj signature.asc Description: OpenPGP digital signature ___ 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
