Now that we have done the first step and migrated Openfire from SVN to git we should discuss how we should proceed. There was already a similiar discussion, called Thoughts on Openfire 4.0 that had a lot of good ideas. But honestly, I consider most of those ideas whishful thinking. In the past, development activity was very low and the developers where poorly connected and very unresponsive.
I’d like to see that changed, and given the recent momentum Openfire developed gained from migrating to github, think that that now is the ideal time trying to change it. Therefore I propose a few measures to improve the development situation:
Nightly development snapshots that produce .deb packages
Establish development guidelines and a policy
Invite more developers to your MUC
Establish a page to motivate developers of every skill level to contribute
I consider this very important and it’s something every open source project should have. If we provide a fast and convinient way to test openfire’s ‘master’ branch, then I expect more users to grab the latest snapshot, e.g. because they want to test a new features, and report regressions and bugs back. Unfortunately, this process has happened in the past with releases, that why it was necessary after the last two releases another bugfix release was pushed only a few days later.
We need to agree on some common policy regarding development and create a document where this is all written down. For example: “How do we name releases?”, “How do we handle branches?”, “What is the relase process?”, “Commit messages should contain the issue key”, “We prefer rebasing pull requests instead of merging them if possible”, “When is it ok to commit something into the master branch?”, “At least X developers should give ‘+1’ for pull requests before they are merged” and so on
Currently it’s only darly and me who idle around in open_chat@conference.igniterealtime.org. It would be great if more contributors would join this room. Chat’s always help to spread information faster und discussing ideas and problems in an informal environment such as an chat produces usually better results then using a forum.
I think we should create a “Volunteer offers” page and set up prominent points on igniterealtime.org to the page. The goal should be to motivite developers of every skill level to contribute to Openfire. E.g. “We are looking for someone who impelements nighlty snapshots .deb packages of openfire and helps us packaging Openfire. Contact Flow for more information”
@ 1) Good idea, but I don’t see the difference to the already available nightly builds (https://igniterealtime.org/downloads/nightly_openfire.jsp) (sorry, I don’t know what a .deb package is and if there were one, I’d use .zip anyway).
@ 2) Might be useful at some point, but currently probably not needed. Might be something for readme.md.
@ 3) Yes it’s nice, but if there’s someone who is interested, he will join by himself. Maybe it can also be included in the readme.md. I think igniterealtime.org advertises the chat every Wednesday which should be enough.
@ 4) I think Jira offers enough issues, where developers can pick some of them up.
@ 1) Good idea, but I don’t see the difference to the already available nightly builds (https://igniterealtime.org/downloads/nightly_openfire.jsp) (sorry, I don’t know what a .deb package is and if there were one, I’d use .zip anyway).
It’s a Debian package.
@ 3) Yes it’s nice, but if there’s someone who is interested, he will join by himself. Maybe it can also be included in the readme.md. I think igniterealtime.org advertises the chat every Wednesday which should be enough.
This chat has never taken place for years now.
Ok, I am not familiar with Debian. Is a tar.gz package not suitable?
The native package format of a distribution offers various advantages over a plain i.e. dumb archive file (be it tar, zip, 7z, xz).
For example, if we would provide nightly .deb builds of openfire in your own debian package repository for openfire, then adventerous users could simply run “apt-get update && apt-get install -t testing openfire” to update their openfire instance to the latest build. All other update precedures, whatever that may be, will be automatically performed by the package manager. Compared to this, extracting an archive file over a previous openfire installation is very error prone and leaves the user with the burden of consulting an upgrade guide.
Thats greate to extend contribution in openfire core and plugin development,
I’m new to openfire plugin development, and familiar with JAVA and Android Development also,
I think Openfire community needs more contribution to make documents for new users, must of the posts are really old and not answered, this is also true for some documents, and aslo better and more sample codes are needed for Openfire Plugin and Smack development.
I write a sample code for file transfer on asmack that fully worked for me, and want to make it a document to help others,