The plan for the next release?

Spark Spark Dev
1

Hello,

Since the announcement last month, has there been any movement on the roles and responsibilities within the community? I’m primarily curious as I’d like to see, and assist if possible, with the next Spark release.

In my opinion, Openfire and Spark represent the best open-source corporate IM solution available. I do believe though, that having no stable release for three years and no movement on the beta for two does significant harm to the image of the software; to be blunt, it looks like a dead project.

So, what’s the roadmap? Who is determining what tasks need to be done to get 2.6 out the door? Is it possible to release a 2.5.9 with no additional features, but with a few minor bug-fixes?

As I said above, I’m willing to do what I can to help the project. In terms of technical skills I’m a bit of a jack-of-all-trades, doing Java development, business analysis, systems analysis and project management. I’m hoping I can fit in about 2-3 hours of work a week.

P.S.

I’m assuming that there are instances of Openfire up and running which developers can connect to, yes? Can’t think of a better way to test and develop then to actively use the product w/ other developers.

2

Hi Neil,

do you want to contribute code? If so please join The specified item was not found…

@PS - Any xmpp server should be fine - I’m not aware of policies which disallow developers to use the servers. As you may have already an account at xmpp:igniterealtime.org you can use this server. It’s running the current beta or even newer code.

LG

3

So what is the answer to Neil’s question? My boss has asked me to evaluate different software because he see spark as a dead project with it being 3 years since a release.

4

Hi,

spark is not a dead project. The last time I work hard on the next release.

I would like to release spark 2.6.0 in november 2010.

The last time we have change and commit a lot in the Spark Project. The biggest change was to replace the commercial packages with opensource projects. Another big change was to move to java 6.

I have finished this the last days. Now I made 2 weeks holiday. After that I will create the new roadmap for the next spark release and publish spark 2.6.0 rc1.

Cheers

Michael

5

Hi

you may ask you boss about the maintenance costs of a commercial solution by Microsoft or IBM. This might lead to the fact that you may want to spend some $ for a commercial developer to fix the issues you are seeing with Spark. I am running 8500 users with Spark 2.5.8 and we went that route (although with internal developers).

CSTUX is accepting patches and the new Bamboo infrastructure (http://bamboo.igniterealtime.org/) will allow a good release.

Walter

6

Since the announcement there were almost no changes in the Spark project. Cstux (Michael Will) is still a Project Lead.

Konstantin (Konstantin Zolotarev) has received SVN access, after doing patches for a long time, and now he’s applying patches to the source too.

Two more contributors (Neil McFarlane and Craig Woodward) have received JIRA access and propose their patches and ideas.

Also, as we have discussed in the “Spark progress/future” thread, Neil has proposed a roadmap and cstux is agreeing in general. So, he says he will try to release RC1 in November 2010. No Beta 3 as Neil was proposing, but this is fine with me. I also agree to Neil’s proposal to reserve 2.6.1 version for 2.6.0 final release’s bug fixes and move other complex, long standing issues to 2.7.0. **Someone has to create 2.7.0 tag for us to be able to do this (Daryl, cstux?), i have sent PM to them about this.
**

We can discuss roadmap here, and then maybe create a doc in this section, e.g. “Spark Roadmap” to outline all the plans, so it won’t be lost in the forums.

Michael, Neil’s proposal was:

  1. 2010 Oct: Beta 3
  2. 2010 Nov: RC1
  3. 2010 Dec: RC2
  4. 2011 Jan: 2.6.0 Final

If we skip Beta 3 and release RC1 in Nov, is this roadmap ok? RC2 in Dec and Final in 2011? We can fix that if we won’t make it in time.

Bamboo already has trunk/debian/rpm automated biulds of Spark. Windows installer or a jar installer are missing. Probably it is not so easy to setup. Cstux? Current installers use IzPack. Maybe it should be somehow integrated into Bamboo. Wonder if cstux has enough privileges in Bamboo to do that. Guus or Daryl maybe can answer that.

But i have another question about the installers. Openfire is still using install4j (commercial?) installer and i see that it works with Bamboo. Maybe we can have Spark still bundled with that installer? For consistency. Or maybe we can have IzPack and install4j installers at the same time? If install4j is easier to setup in Bamboo, maybe we can have it before we can switch to IzPack. I hope cstux can shed some light on this. Because now some users want to test new fixes and patches and not every one can compile new versions and wait till newer installers will be uploaded into “Latest Spark versions” doc. Automated building would be more convenient, for developers too.

7

cstux has created 2.7.0 tag.

8

Thanks for the info

9

A draft for a roadmap document http://community.igniterealtime.org/docs/DOC-2097

10

Hi wroot.

I’m actually hoping that following the 2.6 release we can have a “town-hall” meeting to discuss and determine the future of the Ignite Realtime suite. Ideally, I’d like to establish the following:

  1. Vision and objectives for Realtime Ignite as a whole, as well as for each of the products (Openfire and Spark especially)
  2. The release schedule for each of the products (should we release on specific milestones? On a scheduled timeline? Should the releases of the various products be simultaneous? etc.)
  3. The versioning system we should use as a community for each product
  4. What criteria we should use when categorizing enhancements and defects

And so on.

11

And I think we should clean up old issues. Close or remove dead issues and create description for jira statuses.

12

By this meeting you mean group chat session? Probably we can use one of the scheduled weekly chats on Wednesdays. But we can also set another date and time more convenient for everyone (i usually skip those wednesday sessions because i have other stuff to do).

13

On the JIRA note. I don’t know why it has several ticket closing options (Resolved and Closed), but i would like to have consistency here. We have more Closed tickets, so maybe we should use this option for all of them. Some recent tickets have patches, but not all of them were submitted to svn. And they were marked as Resolved. So, maybe we can mark as Resolved the tickets which has solution, but not yet submitted. Though i would prefer not to mark it Resolved until it is resolved in the latest code.

14

I agree that the Wednesday is a bit inconvenient. I don’t think it has to be a real-time thing though, we should be able to do this through a forum thread; that way we could also do attachements and such.

15

As for me its better to mark issues with patches but not committed into svn as resolved. And issues that are into svn as closed. And the best way is to have “wiating for approve” and “waiting for commit” statuses =)

16

Neil, ok, we can start such thread say in Community Planning (if all planners are watching this group). Although it will take some time for every developer to reply. Some are usually busy with their real work and life

Konstantin. That’s ok. Lets Resolved be equal to “waiting for commit”.