Move to Github organization

[vhda]

I am aware that we are still not using github's organization, so I'm basically using this PR as a way of asking for status information this migration.
In issue #101 we arrived at the conclusion that we should keep "Exuberant Ctags" name.

[vhda]

On this topic:

1. What features are missing for a new release?
2. Does anyone know how difficult it would be to get our updates into Debian, since it's frozen at the moment?

[masatake]

1. What features are missing for a new release?

I labeld some issued "Before releasing".
Critical one is building process. I don't know how to create tar ball.
Man page should be updated to based on docs/*.rst. But I'm not the good person for the job.

[b4n]

I don't know how to create tar ball.

If we used Automake, we'd only have to run make dist (and make distcheck to check the tarball's integrity). The advantages of those tarballs is that they don't require autoconf and friends to work, and can be self-tested.

Otherwise we could make our own thing, like based on git archive. I can try and work something out if you want. The resulting archive would require a Git clone to be able to re-create itself, and would require the same tools to build than the Git repository, but it'd be quite easy to create them.
Such archives are proposed for each Git tag by GitHub too AFAIK.

[vhda]

@masatake how do we move the repository and development to the github organization? I really feel that would give us a more serious appearance.

If no one opposes, I will contact debian's package maintainer to let him know about us, ask him what we need to help him create a .deb package and invite him to contribute (if he is willing to) to our project by adding and maintaining a debian folder.

[masatake]

Yes, I would like to use the github organization evenrywhere we mention ourselves. However, it looks like the situation is still subtle. @ffes, am I correct? Can we move to the repository of github organization?

About contacting package maintainers, I want you to wait because there some compatibility issues. At least I want to stabilize the directory structure about optlib and command line.
However, this is just my request.

[vhda]

I agree with you. But debian is the distro that supports more architectures. If we are to take a debian maintainer on board he would be able to make all those arch tests for us!

[ffes]

I think we should go ahead and move to the organization. First invitation has been sent. But I will start a new issue to discuss that migration.

[vhda]

Started updating documentation.
There is still much to review... @masatake you have been a busy bee!

[ffes]

@vhda Should we change the website URL to github? Shouldn't this be http://ctags.sourceforge.net/

[vhda]

@ffes I have been thinking about this and I have to agree with you. The website that describes ctags is still located at sourceforge. But we will need access to that website when we create a new release! Would you be willing to contact Darren again asking him how we should proceed in that situation? It would also be nice if he could mention the github development area somewhere in there.

[fishman]

i think the right way to do is is to generate a ctags.github.com site from one of the templates and the read me

[vhda]

Creating a new website might confuse users, don't you agree?
As a possible alternative, I've created a new pseudo-tag called DEVURL that points to our github area. This way we can keep both URLs. I can still revert this if you don't agree.
I've also tried to review the documents under docs/. English is not my natural language, so a re-review is welcome.
@masatake please make sure I did not break any of your original text. If I did, I did not do so intentionally.

[masatake]

NOTE: testing.mak is removed. So the docs must be updated.

[vhda]

Everyone, can we move on with this change?
@masatake I'll make the update you requested today.

[ffes]

I think this change must wait until to move to the organization.

[vhda]

My idea was to only merge this PR after the migration is done.
This way everything is already prepared for the migration and then it's a push of a button to commit the changes.

[ffes]

I see! Please ignore this comment.

[vhda]

The requested updates are done.

[vhda]

@masatake, @fishman, @b4n, @ffes, @blueyed, @dtikhonov: we need to reach a consensus regarding the URLs. In these changes I've proposed to keep the original Exuberant Ctags URL on the grounds that we are not forking that project, but continuing its development on a different platform. With this in mind I also added a new "Development area" URL pointing to our new github ctags development area when running ctags --version.

I would kindly ask for your opinion on this subject, such that I can update these commits according to the "democratic view" of the developers.

Thanks!

[blueyed]

I do not have a strong opinion on this matter, but think it's fine like you've suggested.

[dtikhonov]

Having a second URI for "development area" is suboptimal, but given that Darren has resumed his silence I guess it will do. I am in.

[steveno]

+1 for forking. It would appear there is really no other alternative at this point. As pointed out by @majutsushi if the project doesn't start making releases it might eventually fail because no one's going to notice. I also believe hosting on github using jekyll will be fine.

Finally, as for a name omnitags is good. You could also consider utags playing off of "universal tags."

[jsotuyod]

+1 on forking. utags and omnitags both sound great to me.

Starting to make releases and showing sustained and serious development is key to get Linux distros to notice and adopt this instead of ctags.

I agree using alternatives to replace ctags is the best way to go. Probably should change install script to already do so, and state the objective of providing a consistent cli interface to ctags.

From there on, we can start pushing on the support channels for most distros on adopting this as upstream. For those that had patched versions (debian for instance), showing those patches have already been merged is key, to prove adoption is low effort on their end (though risk is still an issue we will have to push for it). The good part is that once one accepts, it should get easier for others. Debian is probably a good starting point, since that will eventually run downstream to Ubuntu, mint, and others.

[masatake]

But I think the name for the program itself should remain "ctags" (ctags.exe on Windows) to ensure compatibility.

I also tihnk so.

I would like to delay the discussion about releasing. Once we released we cannot go back. Many features I introduced during you were asleep is not evaluated well. BTW, don't forget Fedora. I will lose my job:-P

[b4n]

As much as I don't like it, I agree that forking seems the only currently possible solution for moving ahead.
And as someone said, it's always likely possible to merge back in the future if it wanted, just a bit more efforts.

About the name I don't care much. I guess keeping come kind of reference to ctags is important because it's very well known, and well, this is just a follow up development of the same thing. Latest suggestions like universal ctags, omnitags, etc. seem OK to me.

[janlarres]

I would recommended using a different executable name by default, and only adding a "ctags" compatibility link as addition to that, or even letting distributions deal with it. Otherwise programs will have to parse the "version" output in order to distinguish between implementations, like Tagbar is already doing to with GNU ctags, and that is less reliable. It can also create problems if a different ctags implementation is present earlier in the path.

[masatake]

@majutsushi, what is "GNU ctags"? Could you tell me a pointer for it?

I have one more question. In which case, a tool like tagbar has to distinguish the version of ctags?
As far as I know file kind(F) is the only case which breaks tags file compatibility. Are you talking about a compatiblity in command line invoking ctags. In that case, optlib can be used to hide the incompatibility.

[masatake]

I also want to vote. My vote is "universal ctags" as a project name. I guess soon people may use utags as nickname :-P

@fishman, @blueyed, how about you?

[janlarres]

@masatake: I realized that I actually meant BSD ctags, which is included in XCode: https://www.freebsd.org/cgi/man.cgi?query=ctags&sektion=1
Tagbar has to check whether the ctags executable it finds is exuberant-ctags or BSD ctags, since BSD ctags won't work due to its much more limited functionality.

[masatake]

The executable name can be transformed. See at the end of docs/news.rst.

[blueyed]

+1 on forking - it seems to be really necessary by now.
+1 on "universal ctags" and "utags" as a short name. Having still "ctags" in the name is useful to be found.

[ffes]

So when I read all the comments I think most people prefer "universal ctags".

Do we all agree on this?

Shall I just rename the organization "exuberant-ctags" to "universal-ctags"? (Since github.com/utags is already taken we need to use the full name.) That way everybody who was invited back then as team member will remain a member. Other than that nothing has happened yet in that organization.

All we need to do is transfer this repo, but I think @fishman has to do that.

When transfered I suggest everybody to read at least the last section about git remote on https://help.github.com/articles/transferring-a-repository/

[bruno-]

👍

[ffes]

I just renamed the organization to @universal-ctags

@fishman could you transfer the repo?

[ffes]

And pushed a simple placeholder to http://universal-ctags.github.io/

[ffes]

I will send @fishman an email tomorrow to ask him to transfer this repo to the @universal-ctags organization.

With requests like #340 we really would benefit from that transfer. @cweagans own ctags.io and he is offering to link that url to our github pages site!

[fishman]

i just moved it. i haven't had access to my github email and was wondering why my inbox got so silent.

[cweagans]

Looks like this PR needs to be updated to use the universal-ctags org instead of exuberant-ctags.

[vhda]

Please review the updated PR, as it is possible I may have missed some items.

Files that I did not modify:

• FAQ
• README.exuberant
• Exuberant-ctags website files

We should make sure any relevant information is extracted from these files and then remove them.

Coverity scan project ID must also be updated.

[ffes]

@fishman Thanks for the transfer!!!

[ffes]

@vhda I will look at the coverity scan

[masatake]

@vhda, let's merge the changes.