Ola seems unmaintained: Can we help with maintenance?

[aroffringa]

I've mailed to the ola mailing list about this before but didn't get a reply, so I'll try here... I'm noticing that Ola isn't getting maintained anymore. As a result, it is getting dropped from distributions for issues that seem relatively easy to fix, and compatibility with dependencies and newer compilers is becoming an issue (e.g. Debian doesn't ship with Ola because of this issue, which will hit Ubuntu probably also soon, whereas other distro's seem to have issues with an older protobuf dependency). Without packages, people must compile OLA from source, but there are various (though small) reasons that break compilation of the master branch of ola on a few recent distributions. If nothing is done, I suspect OLA will become irrelevant, which I would hate to see.

I've opened pull requests to fix some of the issues (#1989, #1890, #1889), but none of those have been merged into master. @peternewman hasn't answered in any of those pull requests why they aren't merged, which leaves me guessing. I would be happy to improve OLA, but with no way of merging things to master this seems a bit pointless.

My preferred solution would be to have multiple people with merge rights. I'd be happy to be one of them, if just to keep OLA work with a modern setup. Would this be an idea? I think that's better than making a fork, which makes it confusing what version is what, though if that's really necessary I would be happy to contribute to it. Are there more people that feel similar or with ideas?

[nomis52]

I would welcome more maintainers. Those 3 PRs look reasonable, although I'll admit I haven't kept up with C++ since 2015.

If you can rebase those 3 I'm happy to review them (as best I can) and merge. Then we can discuss permissions.

Please mention me and if that doesn't work email me directly. My address is in the git logs.

@peternewman FYI

[DaAwesomeP]

I'll be completely honest--I was contributing PRs some time ago (including one to modernize the Debian package #1855), but it has been years and both the small (#1801, #1862) and large PRs (#1855 is admittedly very large but quite important) have been left behind. I did a lot of work to contribute a KiNET v2 implementation (#1787), and it was merged into master, but that master branch hasn't made it into any new release since (years ago). I stopped contributing after things got to a standstill.

#1855 solves the sysv-init script issue that Debian is concerned about by adding Systemd support. I got approval in that PR from @yoe, who maintains the package on the Debian side of things. @aroffringa if you'd like to take a look I would be happy to rebase! Note that it targets master, and it would probably be some work to port it to 0.10.x. I would be in strong favor of doing some house cleaning and releasing a 1.0.0 that might deprecate some older C++ platforms but will fix these large issues.

I can't commit to maintaining full-time, but I would love to help review PRs and get things rolling again. I think I have commented on or reviewed a few of the PRs mentioned here, but I will take a look at them again after a rebase. @aroffringa please feel free to @ me on anything you'd like a second look at!

[DaAwesomeP]

We should also take a look at #2005 so we an set a clear target of what a cleanup/modernization will look like.

[aroffringa]

Hi Perry and Simon, thanks for the replies, great to hear enthusiasm to get thing moving again :).

@DaAwesomeP I wasn't aware of all that work, that's great to see! On first scan it looks good, and I think getting the Debian package fixed like in your approach is important. I'm happy to do reviews, but I have no write access and so an approval of me doesn't allow you to merge it. But if @nomis52 is happy to give such access to me we could start working that way.

Also thanks for reviewing my PRs. I see you have approved them, but Github tells me I'm still not allowed to merge because I need approval from someone with write access.

Your suggestion to work towards a release 1.0.0 with compatibility for modern systems and dropped compatibility for old platforms sounds great. I don't quite understand the branch and release structure of Ola btw; I'm used that everything gets pushed to the master branch and that this branch gets released every now and then; and only if there are very important bug fixes while master has made a big leap, to back port those. Personally I try to avoid backporting where possible, and just look forward to a new release. I also try to not withhold already implemented features in upcoming release, as I think that the most progress is made when new features are also immediate integrated into releases. With Ola it seems that master has a different purpose, but I could be misunderstanding the release/branch strategy of Ola.

[DaAwesomeP]

I don't quite understand the branch and release structure of Ola btw; I'm used that everything gets pushed to the master branch and that this branch gets released every now and then

It's been a while, but this is my understanding:

• The master branch is currently a "develop" branch where new features are added but there have not been releases
• The 0.10 branch is the "stable" or "release" branch that is being released from, but it does not get new features.
• Select bug fixes that are contributed to master get cherry-picked into 0.10

I think we could move to either of two common structures:

1. main/master branch that is released from. New features go into develop. develop is merged into main before each minor release (as according to semantic versioning).
   • A "minor" release is defined in semver as new features (i.e. 1.0.0 to 1.1.0). A "patch" release is just bigfixes (i.e. 1.0.0 to 1.0.1).
   • Positive: Separates bug fixes from new features, which allows for us to try things out in a develop branch before merging to main.
   • Positive: Patches can be released as soon as possible from main, and develop can be merged into main on a regular schedule for minor/new feature releases.
   • Negative: As demonstrated currently, the develop branch can become too far ahead without regular merging back into main.
   • Currently there is selective rebasing from master to 0.10, which is a time consuming task (to cherry pick specific features to include in 0.10). We would want to do full merges and try to keep them 100% in sync for new minor releases, not selectively merge features from develop to main.
2. A single main/master branch that receives both bug fixes and new features
   • Positive: No regular merging or rebasing required
   • Negative: The codebase can become more unstable as new features are added faster
   • Negative: It is not as simple to release a patch/bug fix without also releasing all of the new features.

[nomis52]

I would suggest development on master, then at release time we cut a branch in case we need cherry picks.

I prefer to release often rather than maintaining support for many branches.

[nomis52]

BTW the 1.0 release was reserved for when OLA would support E1.33 / RDMNet. In my mind that was when I'd consider it "done.

That standard took over a decade though!

[DaAwesomeP]

I would suggest development on master, then at release time we cut a branch in case we need cherry picks.

Sounds good, though I don't think we actually need to cut a branch. If we do need to release a patch for a previous minor version you can just checkout that tag, apply cherry picks, and then release a new patch. I think that will keep the branches a bit tidier/less confusing.

BTW the 1.0 release was reserved for when OLA would support E1.33 / RDMNet. In my mind that was when I'd consider it "done.

I see. I think then it would be important for us to add in the README that we don't follow semver. Deprecating Python 2 and older compilers is a significant breaking change that would normally cause a major version increment.

[aroffringa]

I think that technically semver says that anything before version 1.0 is 'unstable', and so any new version can cause breakage. So if we either use 1.0 or 0.12, either choice wouldn't break with semver.

I don't have a strong opinion myself, but given how stable ola is in general, and that it would be useful to identify breaking changes, jumping to 1.0 might be worthwhile.

[peternewman]

Hi all,

Apologies, a combination of work and personal stuff, both good (and sadly bad) has taken up a lot of my time over the last few years, and also split it up quite a bit, so finding a few hours to get back up to speed with something seems to have got a lot harder.

In terms of 0.11/master, personally I always found it quite challenging that just when it felt like we were coming close to a release, some bug that felt reasonably significant appeared and then I got sucked into trying to fix that for a patch release rather than pushing the minor. For example here's what felt outstanding for 0.10.10:
https://github.com/OpenLightingProject/ola/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A0.10.10%20label%3Abug

As I think I mentioned before/elsewhere (in #2005 ), personally I'd still be keen to release the current master as 0.11.0, for the final one with that range of support, but that has also had a fair chunk of testing from e.g. myself at a lot of Plugfests over the years. Even if 0.12.0/1.0.0 immediately follows it.

Selfishly and also part of the reason I'd suggested the develop/master split elsewhere (for now at least) is I've got an E1.33 implementation that mostly functions, but there's still this huge PR to get in (I'd been breaking it down into chunks that @kripton had been reviewing when we both had time):
#1841

Then on top of that, there's another bunch of files which haven't even made it into commits sitting on my device. Obviously trying to update that past C++11, whilst also splitting it into different bits, and committing the uncommitted stuff would be even more painful than it's currently been.

BTW the 1.0 release was reserved for when OLA would support E1.33 / RDMNet. In my mind that was when I'd consider it "done.

I see. I think then it would be important for us to add in the README that we don't follow semver. Deprecating Python 2 and older compilers is a significant breaking change that would normally cause a major version increment.

Maybe that becomes 2.0.0 then, along with a rework to everything in OLA being a giant E1.33 endpoint or something?

From memory of when I looked at it before, getting onto Protobuf 3 properly will be by far the most painful change. I never managed to work out the exact version of Protobuf that OLA's service builder came from, and it was never committed raw into the repo, so I've never quite worked out which changes it actually had to start with, to rebuild that bit from scratch.

Out of interest, what are everyone else's interests/priorities, are people just interested in the protocol conversion stuff, or doing RDM or? I guess equally what OSes are people using?