Preparation for 2.5M2

Setup, Configuration and Use Runtime
11

But on the other hand goal was to deliver a milestone every month and I guess quite some frequency is needed to get new features/bindings/bugfixes out to more people. Especially after the bigger technical change that will be required to spot the bugs to get to a next release.

Nevertheless a bug making the system generally unusable I’d suggest to be blocking (like the “[core] High load”). Problems with a certain binding I’d comment on when publishing the Milestone.

1 Like
12

Competition 1000%

13

Perhaps we can learn something from a company like Microsoft (no flaming, please) with their Windows 10 release cycle? And it is similar to other release cycle with a ‘Release’, ‘Beta’, ‘Alpha’ type of approach.

Let’s take Windows 10 as an example. For the general public Windows 10 basically has three release cycles:

  • Stable branch (don’t even start! :grin:) - released twice a year. In OH terms that would be like 2.4.x, 2.5.x, 2.6.x, 3.0.x, etc. to be released when ready.
  • Insiders preview ‘slow’ branch - released more frequently but no fixed cadence and reasonably stable, no known breaking issues. In OH terms that would be like a milestone release that is suitable for a wider audience, aiming at bi-monthly I would suggest.
  • Insiders ‘fast’ branch - released quite frequent, usually even more than once a month, but can have some issues/limitations. In OH terms that would be like a monthly release I guess, and the audience would be people that can work with releases and switch between them, troubleshoot, etc.
    And for developers and daredevils, there are of course the nightly builds (snapshots).

The primary reason to bring this up and suggest to consider an intermediate ‘release branch’ is that I have the feeling that releasing a monthly milestone release that is stable enough for many users can be quite a challenge in terms of manpower needed. On the other hand, there is also a need for a fast release cycle to leverage the latest and greatest without great risk to break things (any change to a running IT system can cause issues, believe me, I know!).

For a wide audience OH will have to strike a good (subjective term, I know) balance between fast development/release and stability. As can be seen with HA, people like it’s features but hate its breaking releases. ‘We’ should be different.

I realise that a release mechanism like suggested also results in extra work, but I still wanted to bring it into the discussion.

Just my two cents…

3 Likes
14

This is exactly the plan - fix the blocking regressions and do a new milestone build by then. Milestones are not meant to be “release quality”, so no need to do a fine-grained issue tracking across all bindings etc. It is ok if milestones have bugs, but they should be usable in general.

@noppes123 Thanks for your input. I think what we have in place more or less exactly matches, what you describe: The official releases (target: twice a year) are the “stable” ones, the milestones are the “previews” and the snapshots are the “insiders” builds.

It is only that the whole bnd-build change disrupted our schedule since January and we didn’t have monthly milestone builds since then - this is what we are trying to get back to.

@5iver & all: What do you see as critical bugs left that need to be fixed before a 2.5.0.M2? The CPU load issue is imho one, another one might be the CCE in the SSEActivator. Anything else?

1 Like
15

I see all of these as critical…

1. This one will cause issues for anyone using more than one serial device.
2. Definitely a blocker, but there may be a workaround.
3. A migration script needs to be built.
5. hueemulation is currently non-functional, and IMO, this should be a blocker due to the number of people using this binding.
7. Possibly related to 2.
8. Possibly related to 2.
9. allplay and bluetooth could have enough usage to call this a blocker
10. Blocker, but there may be a workaround.

I’m not as concerned about these…

  1. Since this only affects NGRE on Windows after a restart, IMO it’s not a blocker.
  2. I don’t have input for this one, as mqtt is working for my very limited (Owntracks) purposes with mosquitto as the broker.
16

The Mqtt binding works actually. Open issues are mostly enhancement requests if you see the Homeassistent part as still being in beta.
Unfortunately I lost the Mqtt Homeassistent contributor due to the buildsystem change.

The underlying paho library with its really sad state atm causes problems for script users though. I’m thinking of changing the library after OH2.5 has been released.

Hue emulation also works, but expects json type http posts. Alexa has a defect thought and is sending json with the mimetype plain. There is a fix pending on hueemulation to act more relaxed.

17

So not working. :slight_smile:

18

@5iver I have created https://github.com/openhab/openhab-distro/projects/2 for further tracking.

  • I didn’t include (1) as I understand that this might have been in 2.4 and 2.5.0.M1 as well - so no immediate regression.
  • (5) Do we have an issue for this?
  • (9) I thought to understand that the OSGi-ifying was only relevant for running the bundles in the IDE, but that they are working in the distro?
19

:heart:

I did not experience this issue before the zibee and zwave bindings (the only bindings I have using serial) were migrated to BND.

There are several, but I don’t recognize one specifically for the issue David mentioned… Pull requests · openhab/openhab2-addons · GitHub

I could be mistaken, but I thought there was more to this PR. @J-N-K, could you please confirm, or were the issues reported for allplay, amazondashbutton, bluetooth, etc. something else?

20

Something in between.

  • Allplay has native code, this is not properly declared in the current bundle. This will be solved with the osgiified-bundle, it is also possible to add the osgiified-library in the /lib folder as a workaround.
  • AmazonDashbutton is not installing all dependencies (like XMPP). This can be fixed by removing “dependency=true”. For XMPP I raised #5707 because it is not depending on the OSGi dependency but some other problem. This oculd be done for dashbutton, too
  • BlueZ is a mystery to me. I reverted the lib upgrade done during the migration and added the native code. This SHOULD work and does in my testing VM. But there seems to be a difference between x86 and ARM, which I can’t explain ATM. I’ll see if I can find a Raspi somwhere in the basement and debug it there. Since I don’t own the hardware, it’s a bit difficult.
1 Like
21

Problems with the serial driver have been there longer, with symlinks not working proberly, and not optional from PaperUI. I cant tell for how long though, but this problem was in 2.4 as well.
The latest problems given zigbee and specially z-wave devices problems, was added somewhere in 2.5, where things went from bad to worse… Or in my personal opinion - a disaster!

22

It seems to be fixed for me with the changes in PR #866. :slight_smile:

It’s only an issue when using bindings that use the new serial transport (org.eclipse.smarthome.io.transport.serial) instead of gnu.io directly. In 2.5.0-SNAPSHOT these are: DSMR, EnOcean, PowerMax, RFXCom, Serial Button, Smartmeter, Plugwise, ZWave.

It’s unrelated to the bnd migration. E.g. ZWave switched to using the serial transport in #1152. So the issue is becoming more visible now more bindings are being adapted/implemented using the new serial transport.

2 Likes
23

As I mentioned in the PR, this looks to be working for me too. It’s not merged yet, but I’ve crossed this one off the list. Your efforts are very much appreciated!

2 Likes
24

Maybe this can be solved with the new milestone build too?

1 Like
25

That would be nice too. yet with all the changes that happened, I understand a stable build without too much “new” stuff.
first have the build stable, then make small next steps…(where I do hope it is one of the things fixed)

2 Likes
26

To provide a little context why this would have hit a lot more people in 2.5.0.M2 if it had not been fixed is that the ZWave binding in 2.4.0 did not use the new serial transport. This has been introduced in one of the 2.5.0 snapshot builds to allow people to share the Z-Wave dongle over IP.

27

But no one is able to share it over IP as far as I’m aware?

28

But that IMHO is not a show stopper for 2.5.0.M2 and therefor something for a different topic.

29

So it’s only #674 left on Kai’s list :slight_smile:

30

We should not do M2 with known not-working-at-all problems for bindings. This is at least true for BlueZ (which i still do not fully understand but can be fixed at least temporarily) and Allplay (which is reported to work but not merged).

1 Like