Move openfire svn to github 31 March

Hello,

I would like to proceed with moving openfire’s development to igniterealtime’s github account on 31 March.

If you think this is a terrible idea, please try to convince me otherwise I know we don’t have a formal governance policy with big changes like this, but I am pulling the community dictactor title with this one and wish to move forward.

daryl

1 Like

Community dictator, this is a terrible idea because:

1.-1000.: I forgot the 1000 reasons …

It is a good idea!

Sounds good to me! One less thing for the Ignite admin gang to maintain, and puts code into a widely known respository for open source code.

1 Like

Do we connet Jira and Fisheye/Crowd to Github?

@Benjamin: I think there are still other svn repositories, so an svn admin is still needed.

Yes, there are a few private repsoitories, though, I don’t know that anything NEEDS to be private. Will have to investigate.

I think it is a good idea. I however have questions

  1. Are we moving from Jira to using GitHub issues?

  2. How do we do continous builds with Bambo from GitHub?

  3. Who is taking responsiblilty for reviewing pull requests and applying the changes to Openfire?

  4. Do we move from Ignite JiveSBS to GitHub Wiki?

Well, so far Smack and Spark are both on Github, and the experience has been pretty easy (at least now most kinks have been ironed out).

Jira continues to be the issue tracker for the projects at the moment. Jira offers a lot more features for an issue tracker than Github issues does, however that may or may not be needed. Sometimes simplicity is nice. I think it may be a large effort to get all current Jira tickets into Github Issues… but Github Issues offers a lot more integration when using Github as a repo… I’ve no preference personally.

I believe there is a one-way communication between github to jira (or is it the other way around?). Fisheye, I do not know, however, Fisheye is redundant of much of the Github UI. Fisheye isn’t suggested by Altassian to be used with their Stash product or BitBucket product, and both emulate Github, so it’s doubtful Fisheye will add anything useful for projects on Github.

Bamboo works fine with Github, right now I think Daryl set it to poll Github every 5 minutes for new commits, and if any are found, it builds the project.

Project leads will need to review pull requests (unless delegated to a trusted contributor) and apply changes to the Master branch of the repo (github can email you notifications when a new pull request is opened, and most pull requests can be auto-merged with a 1-click button). When changes are applied to the Master branch, Bamboo will notice, and will build it.

I don’t know about the github wiki. I’ve not used it much… so i don’t know if it offers anything better. If anything, I don’t think we’re going to switch away from using the Jive SBS for forums and the website… so maybe the wiki-ish stuff should stay here as well. I think Matt (or maybe it was Benjamin ) has said at somepoint Jive was planning to upgrade us to the latest and greatest Jive SBS

Thanks Jason (I almost called you Json )

That was very enlightening

Jason pretty much answered for me, but my responses.

  1. No

  2. It is no issue to setup and should work without hassle

  3. That is a good question. I have been privately contacting folks to see who may be interested. The very least will be me reviewing simple PRs and the big PRs awaiting some champion to OK it About like how it is now.

  4. No, SBS will stay.

Sometimes simplicity is nice. I think it may be a large effort to get all current Jira tickets into Github Issues
Yes, simplicity is nice. But the main concern is that migrating from Github issues to another issue tracker won’t be easy because we don’t have access to the Github’s databse. I don’t like the idea giving away data to some company that uses properitary products. At least with JIRA we have access to the raw data, allowing us to do what we want with it.

believe there is a one-way communication between github to jira (or is it the other way around?).
I wouldn’t call it communication. JIRA is connected to fisheye which again is aware that there is a git repo at github. Fisheye uses that repo to build it’s views. JIRA is able to access the Fisheye data and scans the git commit messages for JIRA issues (e.g. SMACK-123) and automatically links those issues to the related commits.

This is a very important feature for me, since it allows me to quickly see the related commits of an issue. The other way around, autolinking the issues mentioned in git commit messages it not really required.

so it’s doubtful Fisheye will add anything useful for projects on Github.
Fisheye has a very powerfull code review system that uses your crowd users. That could become handy. But atm I use github commit webviews to review code of Smack contributors. It’s simplistic and works well. A good example where simplicity is nice. Just wanted to point out that Fisheye has some nice features. Also we need it for JIRA issue/commit linking.

fair points and good info.

There are some plugins (some free, some not) that ease the integration between the atlassian products and github. Although I think we’re pretty well setup as-is. I don’t know if these offer anything better for us, probably not.

(free) - Import Github issues into Jira.

https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-import ers-github-plugin

(free) - integrates git commits into jira issues.

https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-bitbuc ket-connector-plugin

(paid / maybe we can get for free?) - moves code review into jira as well as commit linking for issues.

Regarding Github and getting data out… Github has a very extensive API that allows you to access almost anything… they are very “open data” like that. I don’t think there is any data that goes into Github that one cannot get back out. The Github Issue importer plugin for example, makes use of the API to retrieve Github issues and re-format them into Jira tickets. I’ve not used the Github API myself.

http://developer.github.com/v3/

http://developer.github.com/v3/issues/

Hi Daryl,

YES and no …

I would be really nice to collaborate with pull-requests and other nice stuff from github with you and other openfire contributors. It’s also a good method to establish code reviews of bugs and new features. But I don’t like binary stuff (except images) in a source code repository.

In general I would prefer to push the migration to maven/gradle first to remove the jar-files from the code base and then import the project without history (and without any jar files) to Github. The benefit: With maven/gradle any developer that is new in the project could clone the repository and build it within seconds.

But: I don’t see any progress in the maven-branch. If we want the maven-migration before we move to github we have to schedule a “hackathon” to bring the project to maven at one weekend, otherwise it is stalled again … I’m not sure that we could do that, so yes, lets move to github - with the cons that in every git-clone the binary f*** of the past is in there.

Regards, Sven

Sven,

Thanks for your comments. Yes, migrating to more modern tooling would be great and currently there is bundled JRE in the source tree that bloats the size as well. In my mind, github is the first step and I am hoping that gets more folks engaged. I have gotten some private messages from folks that are chomping at the bit to start sending us PRs. Of course, I don’t reallly have a process setup to handle the complex PRs.

I’m not a good java developer, just good enough to cause trouble. I am hoping that somebody comes along and takes openfire “by the horns” like @Flow did for smack and plows forward with it.

daryl

import the project without history
As much as I am also not a fan of (unnecessary) binaries in a source repository, droping the whole developing history is something I would never consider. Storage space and bandwith are usually not a problem nowadays. Of course, this isn’t a excuse for using binaries in a project, just for not sacrificing the development history in order to drop them.

Most binaries in Smack have been replaced with proper maven dependencies. The binaries left in the (unmaintained and outdated) jingle sub-project soley exists because there was no maven version avaiable and we likely won’t update them.

Moving to github makes sense - even with binaries and all the old stuff. If one has the time to fork it and create a new repo without all the old files/history it would be great. Anyhow this could mean that it takes ages to move to github. I could live also without history as there were not to much changes in the last years. And there is always the old repo.

one could always remove the binaries from the history tree with “git filter-branch”, effectively “re-writing history”, but while keeping the rest of the history.

https://help.github.com/articles/remove-sensitive-data

possibly followed by:

http://stackoverflow.com/questions/11255802/after-deleting-a-binary-file-from-gi t-history-why-is-my-repository-still-large

Yes, I am all for doing that step once we get things moved over and code updated to no longer need them.

I still have to figure out how to use this newfangled “maven” thingy.

I have a question related to the whole setup. Is Fisheye still going to be used for commiting (not sure what exact role is, reviewing?)? I use fisheye’s RSS to monitor commits. And the latest Jason’s commits to Spark didn’t showup. I presume because it was done on github and Fisheye can’t see it or is not setup to see it. Or should i monitor the guthub now? Does it have RSS for commits?

wroot, I monitor fisheye’s RSS for commits and github’s commits do show up there. You may need to update your subscription. I use

http://fisheye.igniterealtime.org/changelog?RSS=true