Two week planing to Spark 2.6.0 RC2

General Discussion Community Planning
1

Hi

I would like to propose a two week schedule for driving the open 2.6.0 bugs down to zero for RC2.

There are four main issues open in 2.6.0:

  1. Clean error log

This will possibly require a rework of the threading of the app during start.

  1. Reconnectivity issues

There is a large change baking in our internal trunk that closes all opoen issues documented in Jira. We will also redesign the behaviour of Spark during reconnection

  1. Open I18n files

This is Lithuanian and Polish.

  1. Smack 3.2b2

This is controversial in the dev group. I would suggest to use the 3.2.0 beta to identify issues with it. Early results that this is really useful, as some Smack issues show up during testing and error log cleaning. The critical question: Would be go final with a Smack 3.2.b code. Obviously No. I hope to get Robin Collier to move Smack along Spark 2.6.0. But RC2 should have Smack.3.2 inside.

The timeline for this is highly agressive: Two full weeks of concentrated effort until March 20.

Everything that is out of reach on March 17th should be pushed to 2.6.1.

We would also propose a larger code formatting change in the Spark SVN. We would like to do that between the 7th and 10th of March.

What’s the community opinion about that?

Walter

2

That would be SO good. Excited to see it out of beta

3

i18n files are not so important to be called an issue. They can be pushed to later versions (though i see no errors with them and they probably can be added easily).

I don’t mind to use Smack Beta to test how it works with the latest Spark code. But what if Robin won’t get it in time for March 20? Changing to prior version again is not an option. I think Robin should say is it possible to have Smack final release in two weeks.

Explain what you mean by formatting change in the Spark SVN.

4

The code formatting is basically a setting how to use TAB and spaces as well as code line lenght. This increases readability for the developers quite a bit. Itis not a change in code but in it’s format.

Mike and Wolf discussed it here: http://community.igniterealtime.org/thread/43909?tstart=0

The proposed format is somewhat a standard.

A change in format is a large change (size) that will require all developers to reload their SVN copy completely.

5

With resepct to Smack: We are seeing several error log entries and “features” that might point to Smack 3.2.0 B2. To get a proper code test for Smack 3.2.0b2 it is somewhat mandatory to have it in RC2 as a beta.

The inclusion of Smack 3.2. instead of 3.1 was no big issue. We have the option to release 2.6.0 with 3.1 or 3.2 depending on the Smack status. It would be premature to decide the Smack version right now and it is not necessary right now

6

Exactly why would you like to do this reformatting? I’m very much opposed reformatting the existing code. It will make comparing code with its previous state impossible, something that is a valuable analytical practise to loose.

7

Since there were nearly no people in favour of doing a large code formatting, we will leave it as it is.