search

openhab / openhab-core

Core framework of openHAB
https://www.openhab.org/
Eclipse Public License 2.0
907 stars 420 forks source link

Improve the openHAB Bill of Material (BOM) artifacts to assist third party addons in an easy way #2925

Closed FSeidinger closed 2 years ago

FSeidinger commented 2 years ago

Not long ago the marketplace of openHAB was opened. I got the impression that the marketplace is an initiative to further encourage development outside the openHAB repositories. And for me it addresses several disadvantages of developing with focus mainly on addons.

  1. There can only be one "official" addon for a given task or technology. This, IMHO does not lead to a healthy competition and struggle for the best solution.
  2. You have to use a very big, monolithic maven reactor build that comes with a lot of rules, settings, configurations and dependencies which are in no way necessary to build just one third party addon in good quality.
  3. It takes a lot of time to introduce, advertise and convince the maintainers to add your addon to the official list of addons. This costs a lot of time an effort just to have a develop a third part extension.

To improve this, I would like to make the suggestion to improve the openHAB Bill of Material (BOM) projects. Currently they to not adhere to the maven standards for BOMs, especially in the field that they do not configure the dependencies in a dependencyManageemnt section of the POM.

Having that, a third party developer can start with a clean and fresh maven project, importing the necessary dependencies via POM and is good to go.

This feature request was opened by me after being encouraged by openHAB members in the openHAB forum thread below:

https://community.openhab.org/t/increase-openness-and-competition-on-components-developed-outside-the-official-source-code-repositories

openhab-bot commented 2 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/increase-openness-and-competition-on-components-developed-outside-the-official-source-code-repositories/135183/21

hmerk commented 2 years ago

I got the impression that the marketplace is an initiative to further encourage development outside the openHAB repositories.

I am afraid that you misunderstood why the addon marketplace was introduced. Main reason was to give developers an easy option to publish their bindings for testing, while the according PR ist still in the review queue.

cdjackson commented 2 years ago

Even if this is the case, maybe it should be extended? I think I say that @J-N-K has recently added the ability to add multiple marketplaces, so this also seems to indicate (to me at least) the intention to move to a wider distribution system?

To me it makes sense that users can easily develop their bindings without the huge infrastructure that is currently required (ie pulling down every addon). Allowing people a simpler route to development must be a good thing - the marketplace then makes it possible to distribute these addons.

Trying to pull every possible addon into the openhab monolithic repository does not seem to be an approach that scales well - as we've seen. There are too few maintainers to require them to review every possible binding that people may want to produce. If we're saying that the marketplace is only there as a route to inclusion of bindings into the official addons repository, then I think we are missing an opportunity to make OH more progressive.

FSeidinger commented 2 years ago

I am afraid that you misunderstood why the addon marketplace was introduced. Main reason was to give developers an easy option to publish their bindings for testing, while the according PR ist still in the review queue.

Maybe but then the description of the forum must be wrong as well:

image

That clearly says that the addon marketplace is there to share addons with other openHAB users. That does not sound like a staging or testing only area.

And a lot of addons I see there are not official ones and do not want to become official ones.

clinique commented 2 years ago

Agree that sometimes it's tough to have your addon integrated but also, once it is in the official addon list, as a développer, you do not have to take care of each and every framework evolution that could deprecate it when isolated in the market place. And isolated add-ons will not be a problem for developpers only, but also for users. Personally, I prefer having PR staled for some time, than having my home automation system relying on individual efforts. As an example, I really like what @J-N-K produces on his personal repo, but I always think of it twice before making them part of my system.

J-N-K commented 2 years ago

@clinique I believe the discussion is a bit off-topic here, but IMO your points are not valid.

If a binding is part of the official repository, it is ensured that they COMPILE with all core changes. That is different from ensuring a binding WORKS. One prominent example for that is mail, which is broken since month due to changes in core or distro. There have been others in the past which I don‘t remember ATM.

Also having a binding in the official repository does not prevent it from being abandoned. If developers leave, chances are high that development of an item stalls and changes in protocol are not implemented (which may render the binding useless) or bugs not being fixed. amazonechocontrol or mqtt are only two examples.

zigbee or zwave are usually in good shape, even if they are not managed on openhab-addons.

The point is: it‘s always up to individuals as long as developers are not paid for their work. There is no guarantee for broken or working add-ons for either place of development.

I see the difference in another point: whom do you trust that she/he‘ll not distribute malicious code. Depending on how much confidence you have in the developers/reviewers, the risk for a larger repo with detailed review by others might be lower than that of a smaller group or an individual.

splatch commented 2 years ago

I would love to separate philosophical aspects which belong to forum and focus on technical merit here. Lets have together a look on technical facts and what this issue means for project and its ecosystem. A long time ago I had a look on articles outlining "Architecture Decision Record" as a way to document project changes, motivations and so on. Some people that Architecture might also mean "Any". ;-) I will try to follow ADR template in outlining what, why and maybe how we can approach this problem.

Simplify externalized development through publishing of Maven's bill of material (BOM)

Summary Maven BOM pom files are special kind of "parents" which allow to define dependency versions which are used in project. Other projects can import such dependency definitions and rely on them in order to achieve compile and often runtime compatibility with publisher of these. The BOM approach got popularized by Spring Boot and got adopted in many popular Java projects as a way to simplify management of dependencies in small but also large projects. While openHAB defines its "BOM" model (compile/runtime/test) its not aligned with definition of what the "bill of materials" POM is.

Context At present openHAB does not publish any kind of useful BOM with own artifacts and used dependency definitions (ie. what it uses and in which versions). There are only "parent" poms which are used by openhab repositories which define fairly long list of compile dependencies in an unmanned way. This means that someone who needs an access ie. to DiscoveryService interface will get all openHAB artifacts on its classpath, even if its addon is two or three classes which are fine with osgi component annotations, core.config.discovery. Additionally published POM files contain several plugins which require very specific project setup in order to even run a build. Simply speaking they are not very useful for small and quick work, they also impose serious constraints (alignment) for larger projects.

Solution A solution towards simplification of third party development is official support for BOM files which could be used just to import openHAB dependencies. BOM files can be divided similarly like current BOM - into compile and runtime or other scopes after further discussion.

Consequences There are several consequences in taking this decision. Primary place which will be affected is openhab-core which should publish BOM, other repositories shall stay unaffected or affected in minor way (no updates expected there). Changes in openhab-core are limited to work in POM files which will extract dependency management sections from existing dependencies. No compile changes are necessary, no backward compatibility in code will be broke. Technically speaking this change have small impact on openHAB itself. There are however ecosystem consequences which can't be ignored. From major pros and cons we can mention: 1) :heavy_minus_sign: Negative side is possible lowering of quality of third party addons which are not supervised and aligned with static analysis, null checks and other things provided by openHAB pom files. 2) :heavy_plus_sign: Broadening of addons available to openHAB through simpler way to build bindings requiring smaller afford from first time contributors.

Pros/cons can't be solved by BOM files themselves. Even now, openHAB as a project can't really block development of third party addons. It can't make it much harder than its is already - lack of artifacts in Maven central, external repository, lack of BOM files all this make it fairly hard, even to seasoned Java developers, to get any addon outside of openHAB setup. Given that BOM files are fairly popular in Java land it does not require much of documentation for experienced developers. Unless there is a policy change to promote this way of development over existing centralized addons repository. An additional section of paragraph in developer documentation might be sufficient to mention coordinates and use of BOM files for people who would like to rely on that approach.

Status

Current status of this document is proposal.

Decision

Core maintainers: [x - yes, x-no, x-abstain] Architecture court: [x - yes, x-no, x-abstain] Resolution: Accepted / Declined

References

Github issue: https://github.com/openhab/openhab-core/issues/2925 Forum topics:

openhab-bot commented 2 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/increase-openness-and-competition-on-components-developed-outside-the-official-source-code-repositories/135183/22

J-N-K commented 2 years ago

@splatch I have read your proposal in the forum thread from 2019. My understanding is that you would like to see a BOM that is a copy of org.openhab.core.bom.compile, org.openhab.core.bom.runtime and org.openhab.core.bom.openhab-core with the same content but within a <dependencyManagement> block? From my understanding that would allow us to use everything like we had it before. Is that correct?

splatch commented 2 years ago

It's good question how to organize it, cause now each bom contains bunch of dependencies which are used elsewhere in semi random fashion (you don't know which of dependencies are consumed by what). A risk which is not materialized yet is a situation when one of third party dependencies defines a an upper or lower version of same artifact (think of gson, guava, jackson, slf4j), then you get non deterministic results as first element on classpath wins.

I suppose that org.openhab.core.bom.compile must stay intact while we need to define a proper bom using different artifact id, ie. org.openhab.core.proper.bom.compile which will make copy of `org.openhab.core.bom.compile dependencies inside <dependencyManagement>. As you said, same steps have to be repeated for openhab-core and openhab-runtime.

I suppose that a proper compile bom (org.openhab.core.proper.bom.compile ;-)) could look like this:

<project>
  <parent>
    <groupId>org.openhab.core.bom</groupId>
    <artifactId>org.openhab.core.reactor.bom</artifactId>
    <version>3.0.4-connectorio-1</version>
  </parent>

  <artifactId>org.openhab.core.proper.bom.compile</artifactId>
  <packaging>pom</packaging>

  <dependencyManagement><!-- must use dep. mgmt -->
    <dependencies>
      <dependency>
        <groupId>org.osgi</groupId>
        <artifactId>osgi.core</artifactId>
        <version>6.0.0</version>
      </dependency>
      <!-- rest of the ... deps coming from core.bom.compile ->
    </dependencies>
  </dependencyManagement>
</project>

Then legacy bom (existing org.openhab.core.bom.compile) becomes this:

<project>
  <parent>
    <groupId>org.openhab.core.bom</groupId>
    <artifactId>org.openhab.core.reactor.bom</artifactId>
    <version>3.0.4-connectorio-1</version>
  </parent>

  <artifactId>org.openhab.core.bom.compile</artifactId>
  <packaging>pom</packaging>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.openhab.core.bom</groupId>
        <artifactId>org.openhab.core.proper.bom.compile</artifactId>
        <version>${project.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <dependencies>
    <dependency>
      <!-- note, you don't need any version in any of declared dependencies, they are promoted from proper.bom -->
      <groupId>org.osgi</groupId>
      <artifactId>osgi.core</artifactId>
    </dependency>
  </dependencies>
</project>
lolodomo commented 2 years ago

Just a quick opinion: for the global quality of addons and openHAB in general, I think it is a massive advantage to have an official repo containing bindings that were reviewed and for which you are certain they are compiling with the distribution they are packaged. When you are a reviewer, you realize how the quality could be reduced without this step. And when something is changed in the core framework, a good core contributor will generally check what are the impacts on all the official bindings and will eventually submit a fix to the impacted bindings. I can also mention that the bindings in the official repo are automatically available for translation.

Providing PRs to the official addons repo is clearly the preferred option IMHO. So I would suggest (even if I am absolutely deciding nothing myself here) to keep something simple and reliable for the build and the development for the official stuff.

If there is a technical solution for developers who really want to be outside the official stuff for some obscure reason, why not.

FSeidinger commented 2 years ago

If there is a technical solution for developers who really want to be outside the official stuff for some obscure reason, why not.

From how you set the arguments, you stress the technical part of solutions. I learned in my hard way to an IT expert, that technology is never the problem in groups of people. It's the politics (as known as policies) and the behavior of the individuals in groups that are complex.

So my list you will find very few technical reasons why developing outside the official repository might be beneficial. And I guess I repeat myself here over and over with the same arguments:

  1. Competition. In the official repo there can only be one binding per technology. From the market point of view this is a monopoly and as such primarily designed to restrict the solution space.
  2. Restricted choice of users. A user cannot choose between concurrent solutions.
  3. Restricted sovereignty of users. You force the user into your solution space and reduce the ability to participate and influence other solutions.
  4. Efficiency. If there is a monopolistic protected solution, if has no incentive to be efficient for the user.
  5. Regulations. The official build sets a lot of regulations, like line endings, code style, licenses, etc. Don't get me wrong, I'm convinced that you need quality assurance, but you should choose them for yourself.
  6. Build time. A full build of the bindings project runs on even fast machines about an hour. This is simply unacceptable for just compiling and testing a new binding/approach because it wastes my time.

And there are many more. So most of the time I would mandate for a free binding development outside the official binding tree.

hmerk commented 2 years ago
  1. Competition. In the official repo there can only be one binding per technology. From the market point of view this is a monopoly and as such primarily designed to restrict the solution space.

I have to disagree to that point. We already have the situation to have some bindings being in the official repo and having a "third party" version in the marketplace. Users are irritated, why there are different bindings for the same technology available and which one to chose.

Why not join forces and improve an existing solution/binding instead of reinventing the wheel.

splatch commented 2 years ago

We either discuss a) technical side of a core which was promised to be a framework which ESH never have been, or b) approach towards management of openhab as a product.

I'd favor to move all addon/policy related things away (to forums or AC) and focus on a problem OP brought. It is strictly speaking a technical thing.

hmerk commented 2 years ago

I'd favor to move all addon/policy related things away (to forums or AC) and focus on a problem OP brought. It is strictly speaking a technical thing.

Sorry to disagree here as well, but the problem the OP brought up is about making changes in the core to change the way addons are bundled/developed. So those two cannot be moved to different discussions.

splatch commented 2 years ago

Given lack of better document I can only use @kaikreuzer post: https://community.openhab.org/t/the-road-ahead-reintegrating-esh/64670 where he stated:

We would like to keep openhab-core in a “framework-style” similar to ESH, so that it is possibly to package it in different ways and that it is not only usable by the openHAB distro.

Also going over official docs: https://www.openhab.org/docs/developer/contributing.html I can see that "framework" statement is repeated:

openHAB Core: This repo contains the core framework bundles of which the openHAB runtime is constructed. openHAB Add-ons: Add-ons (such as bindings, voice services, etc.) of openHAB can be found within this repository. openHAB Distro: This repo contains all parts that are required for assembling the binary distribution of openHAB.

Assuming that above are still some kind of reference, as Kai post dates prior establishment of current governance policy, plus framework context is still retained, plus contribution criteria still say that PRs/issues are welcome, all this discussion is simply unnecessary. I don't see in contribution docs that only issues/PRs which build up OH-distro functionality are welcome and framework is reserved for OH distro exclusively nor that third party addons are prohibited.

Be so kind and update docs if above are not up to date and framework dream fade, again, away.

J-N-K commented 2 years ago

openHAB Core is (and should be) considered as a framework. This is also part of our development principles, e.g.

The community marketplace is a completely unrelated issue. It is openHAB Distribution specific, as it relies on the forum provided by the openHAB Foundation. TBH, IMO it should removed from openHAB Core and either be part of openHAB Distribution or openHAB Add-ons. What is provided there is up to the openHAB Foundation and if I'm not mistaken, all competing bindings have been removed (if that is not the case, forum moderators should take care of that, it has nothing to do with openHAB Core).

Besides other solutions, it may well be that advanced users would like to create an add-on that is for private use only. As an example from the german FaceBook user group: someone wants to have an interface to enter data that'll later be processed. This is a very specific thing that can easily be done by using a servlet and has no value for anyone else. It makes no sense to integrate that into openHAB Add-ons or require following openHAB code style for that. Another example would be some home-made DIY hardware with a proprietary protocol that only exists at the creator's home.

The changes proposed here do NOT affect the way add-ons within openHAB Add-ons are developed. It was made clear from the beginning that every change has to be minimal invasive for the current build. So all that is requested here is that creating add-ons for specific use-cases is supported in a better way than it is now.

Regarding re-inventing the wheel or joining efforts: There is a very good example in openHAB Add-ons at the moment, why people oppose to the one-technology-one-binding policy and try to go other ways. The Netatmo binding undergoes a complete rewrite which will require every user to completely re-configure her/his system and set-up completely new things. If it was up to me, such things would never be merged, because the benefit of the re-write usually does not win over the hassle with breaking existing installations on upgrade. From my understanding, @FSeidinger wants to do something similar with the KNX binding, which is probably in even more widespread use and would upset hundreds of users. But this is policy alone, it has nothing to do with the technical aspects discussed here.

BTW: I do not agree with 6. on the list above. When developing in openhab-core I usually build only single bundles (mvn spotless:apply clean install -DskipChecks -pl :artifactId) which is super-fast and only do a full-build before pushing to GitHub to make sure all bundles can be build, and all unit and integrations tests pass. The same can be applied to openhab-addons.

clinique commented 2 years ago

Regarding re-inventing the wheel or joining efforts: There is a very good example in openHAB Add-ons at the moment, why people oppose to the one-technology-one-binding policy and try to go other ways. The Netatmo binding undergoes a complete rewrite which will require every user to completely re-configure her/his system and set-up completely new things. If it was up to me, such things would never be merged, because the benefit of the re-write usually does not win over the hassle with breaking existing installations on upgrade.

Sorry to say @J-N-K , but I really feel offended here. Current version of the binding is stuck since more than 3 years because of its technology, relying on swagger and other external libraries. Not handling 30% of available modules and devices. Every time I work on a binding dependant on external libraries, I swear such it's nightmare to deal this case. I have chosen to rebuild it from scratch,even rewriting oAuth2 process because of a specificity of Netatmo API. More than 10k lines of code and I really hope it will be merged because I need external views.

J-N-K commented 2 years ago

I have no say in openhab-addons, so it's just my personal opinion that less work for the developer (and I understand your issues there, I hate some external dependencies, too) does not outweigh more work for the user. Looking at core, I would prefer dropping xtext/xtend (and with that all DSL rules and non-JSON configuration), but this is just not possible without a way of migrating the config.

Edit: just to be clear: I do appreciate the efforts you put into the Netatmo binding. The problem is that openHAB does not provide a smooth path for migration.

lolodomo commented 2 years ago

Regarding re-inventing the wheel or joining efforts: There is a very good example in openHAB Add-ons at the moment, why people oppose to the one-technology-one-binding policy and try to go other ways. The Netatmo binding undergoes a complete rewrite which will require every user to completely re-configure her/his system and set-up completely new things. If it was up to me, such things would never be merged, because the benefit of the re-write usually does not win over the hassle with breaking existing installations on upgrade.

Sorry to say @J-N-K , but I really feel offended here. Current version of the binding is stuck since more than 3 years because of its technology, relying on swagger and other external libraries. Not handling 30% of available modules and devices. Every time I work on a binding dependant on external libraries, I swear such it's nightmare to deal this case. I have chosen to rebuild it from scratch,even rewriting oAuth2 process because of a specificity of Netatmo API. More than 10k lines of code and I really hope it will be merged because I need external views.

Small off-topic: considering @J-N-K good argument, I am asking myself if we should not keep the current netatmo binding in 3.3 and consider it as deprecated and the new binding will be added (with a different name, like for example netatmo2). That way, no user will be immediately affected; they will have 6 additional months to move from binding netatmo to binding netatmo2. 6 months later, OH 3.4 will only contain the netatmo2 binding. And we could update the original netatmo binding before 3.3 is released to show to the user that it is deprecated.

splatch commented 2 years ago

I am asking myself if we should not keep the current netatmo binding in 3.3 and consider it as deprecated and the new binding will be added

Maybe its also a good idea to discuss either internally (within maintainers) or externally (on forums/issue) how to better address migration issues in future OH releases such as 3.4 or beyond.

hmerk commented 2 years ago

with a different name, like for example netatmo2). That way, no user will be immediately affected; they will have 6 additional months to move from binding netatmo to binding netatmo2. 6 months later, OH 3.4 will only contain the netatmo2 binding. And we could update the original netatmo binding before 3.3 is released to show to the user that it is deprecated.

According to todays contact from Netatmo API development and the therefore opened issue #12677 by @digitaldan, wouldn‘t that double the effort, as we need to change auth method until September 1st 2022 ?

lolodomo commented 2 years ago

with a different name, like for example netatmo2). That way, no user will be immediately affected; they will have 6 additional months to move from binding netatmo to binding netatmo2. 6 months later, OH 3.4 will only contain the netatmo2 binding. And we could update the original netatmo binding before 3.3 is released to show to the user that it is deprecated.

According to todays contact from Netatmo API development and the therefore opened issue #12677 by @digitaldan, wouldn‘t that double the effort, as we need to change auth method until September 1st 2022 ?

I understand that the old netatmo binding will stop working for this reason the 1st of September as it will not be maintained anymore (we are switching to the new binding). This will be an argument in favor of replacing the old binding by the new one. This discussion will continue in the PR of the new netatmo binding.

J-N-K commented 2 years ago

After re-reading the discussion here I do not see any argument against an externally usable BOM and would be willing to re-view and eventually merge a PR for that.

Some thoughts:

FSeidinger commented 2 years ago

As already laid out in the forum, I withdraw my request, because the project/maintainers where not able to give any reaction to a users request.

lolodomo commented 2 years ago

You got a feedback, especially from @J-N-K who is a core maintainer.

FSeidinger commented 2 years ago

You got a feedback, especially from @J-N-K which is a core maintainer.

Did I miss something?

Assignees: No one assigned Labels: None yet Projects: None yet Milestone: No milestone Development: No branches or pull requests

spacemanspiff2007 commented 2 years ago

would be willing to re-view and eventually merge a PR for that.

So if you create a PR J-N-K will look at it. I understand it that way that you should provide a PR, so the todo would be on your side.

J-N-K commented 2 years ago

Projects are never set, milestones are used for tracking merged PR to generate the Changelog.

Assignments are rarely used, mostly in cases where someone is working on an issue but there is not enough to make a PR out of it (so double work is avoided). If you declare that you are working on the issue, I would assign you.

I can only speak for myself here: this has no top priority to me, as it does not affect the user. There are other issues which are much higher on my to-do list (and waiting much longer for a resolution). My time is limited, I have a job to earn a living and a family. Nevertheless I offered to review and merge if a contribution is made. This has not happened.

rkoshak commented 2 years ago

I just want to reiterate that the response on this issue is about as good as it gets. There was a great discussion. No maintainer is objecting to the idea nor the overall approach. You actually have a maintainer agreeing to review and merge such a change. That's pretty much a guarantee that this issue will be included, but only if someone volunteers to work on it.

@FSeidinger , if your problem is that no one jumped up and volunteered to implement your idea well, your expectations are not reasonable. The only things that get done in openHAB are done because someone self volunteered to do it. You can have the best idea in the world but if you don't have someone to volunteer to do the work, the idea is worth nothing. No one here is your employee nor an employee of the openHAB project. No one can force anyone to work on anything. It's all self directed and self motivated.

Consequently, as Jan explained, assignees are rarely used and all the rest are used to track what's already been done, not to drive future work. They'd be worthless for that because we can't direct future work. The direction that OH goes in bubbles up from the bottom, not driven from the top.

Do you expect us to say, "sorry Jan, adding that DateTime Item trigger is great and all, but it's not on the roadmap. You need to solve @FSeidinger's issue first." ? How long do you think he'd stick around and contribute to OH after that?

So do the work to create a PR or find someone who will do the work for you and you have a near guarantee that it will be merged.

splatch commented 2 years ago

I have a mixed feeling. Seems that everyone but Frank is fine about resolution of issue. Frank requested improvement, Frank haven't made it. Frank resigned from pulling it over. All clear.

Yet none of problems outlined in related forum topic nor in above discussion is addressed. So far, after a month of struggle we come to the point that making a BOM was fine, cause one of core contributors agreed for it.

Please take care of clearing out "what's welcome" and "what's not". Otherwise, with time, more and more work towards openHAB will end up as above. Simply abandoned. Can't you see all arguments (politely speaking) which were between start of Frank forum post up to closure of his issue today? Somehow all of you become active and started to send emojis on github. Why you weren't that active making a voice about underlying issue itself? Are you shy? Where is a clear acceptance criteria for third party contributions, where is your voice in guiding the project? All above questions are towards @kaikreuzer, @wborn, @rkoshak (I can't name fourth AC member).

rkoshak commented 2 years ago

Why you weren't that active making a voice about underlying issue itself?

I typically don't have a position on development issues and mainly towards end user facing issues. I'm not a maintainer nor really even a developer on OH itself so it's not my place to offer opinions on how something gets implemented or how add-ons get developed and built and the like. This issue isn't a user facing issue so beyond answering some questions on the forum with information about the AC I don't have an opinion on how or whether the above is a good idea. It sounds good to me and that seems to be the consensus too.

The discussion above was good. It looks like most if not all agree this is a problem that needs to be addressed and some bounds were placed on that and a promise to review and merge any PR was made by a maintainer. It looked like this issue was heading in an excellent direction.

I raised my voice on the issue now because, honestly, I think that closing the issue is a mistake born out of a miss-understanding.

Where is a clear acceptance criteria for third party contributions, where is your voice in guiding the project?

I can't imagine what clearer sign of an acceptance criteria for this issue could be made beyond Jan's promise to review and merge a PR if that PR meets certain technical constraints .

In short, this issue was closed not because people think it's a bad idea or that there is strong resistance to change. the issue was closed because OP assumed that having the good idea is enough and expected someone to assign this task to a developer to implement for him. As we all know, that's not how this works. If OP can not or will not volunteer to implement this himself, someone else has to volunteer to do it.

So, out of frustration that someone hasn't immediately volunteered to implement his idea, OP chose to close the issue, immediately turning what looked like was going to eventually become a success into an abject failure.

All above questions are towards @kaikreuzer, @wborn, @rkoshak (I can't name fourth AC member). @ghys

As for the AC involvement, where's the conflict among maintainers here? The only conflict appears to be that the OP is upset that someone else won't immediately volunteer to implement his idea for him. That's not an AC issue. Do you want the AC to start assigning tasks to volunteers? In that case I as a member of the AC hereby assign @splatch to implement this issue. Feel free to tell me to "go pound sand" since we both know I don't have the power to tell you what to volunteer to work on.

ghys commented 2 years ago

I didn't react initially to these discussions as I deal pretty much only with the UIs that I've created so the politics are somewhat simpler - until the overwhelming majority of the code in my area isn't mostly mine anymore, I don't feel I should shy away from acting as the BDFL of that area (but I insist on the "B"!).

My 2c on what an "acceptance criteria" should look like can be figured out from the contributing rules as it's a case-by-case affair, there's no definite generic answer.

We don't want it to do everything for everybody. This means that we might decide against incorporating a new feature.

The guidelines encourage a contributor to properly discuss a major improvement that brings a new idea, or could have repercussions with potentially controversial aspects before starting working on it. You want to make sure that such a change gains traction and the potential pain points be addressed first, otherwise what happens is you "shame" the maintainer into accepting that change or feel guilty of rejecting hard work that wasn't necessarily desired in the first place. That's wasted time for the contributor, a guilty feeling for the maintainer and therefore a negative mood all around. So IMHO the "Pull Requests are Always Welcome" title isn't that simple :) It definitely is for uncontroversial stuff.

J-N-K commented 2 years ago

Without code (and that usually is a PR) most issues (this one is an exception if you look through the open issues with either breaking changes or more difficult code, e.g. #1216, #1393, my personal favorite #1924) are either not discussed at all or end up stale at some point without a definite decision being made.

So we have a sort of chicken-egg-problem here: with code, it's very likely being reviewed (not always as soon ad would be preferable, but at some point it will). In most cases this results in the feature being incorporated, in some cases work is lost and the contributors time is wasted. Without code chances are high that the feature will never make it into the code, because the discussion never finishes.

This issue here is IMO different: It was a very fruitful discussion which ended - after an acceptable time - with a clear guideline what needs to be done to get it merged. I spent quite some time for the discussion here and thinking about what requirements a PR should fulfill. Since no-one stood up to realize it, this wasted my time.

To sum it up: if you provide code or start a discussion first: There is always the risk of someone's time being wasted. I personally prefer code over discussion, a good example of why I think that way is #1924: Since no-one knows how to implement what can be considered as a "result" of the discussion, a fits-most-solution is not implemented. If there had been code in the first place, likely it would have been the other way round.

splatch commented 2 years ago

I don't really want to turn this issue into a forum post, as its closed without resolution and problems outlined there will just stay with us for few more years.

until the overwhelming majority of the code in my area isn't mostly mine anymore, I don't feel I should shy away from acting as the BDFL of that area (but I insist on the "B"!).

As a programmer I understand this point, yet there is a fine line between leading and dictating things. If someone needs to spend endless hours to get an agreement for changing a basic thing which is technically justified, its not leading, its blocking things. Surely, sometimes its hard to determine. How would you read situation when every larger change touching a core aspect is blocked over years, technical debt is growing in linear scale and code which doesn't get used or its use is easy to test, is fenced and protected from refactoring?

On this point I can also mention that main ui is youngest component in openhab sub-projects so situation there is different than in core which is already 10 years old. If we take a eclipse smarthome as a starting point of OH 2.x, its first tagged release, is September 2014, was 8 years ago. The core repository had more people working on it hence code ownership there is not as strong as in UI. It is somewhat reflected in code owners: https://github.com/openhab/openhab-webui/blob/main/CODEOWNERS https://github.com/openhab/openhab-core/blob/main/CODEOWNERS (still a bit anonymous as exact list is visible only to certain people)

My 2c on what an "acceptance criteria" should look like can be figured out from the contributing rules as it's a case-by-case affair, there's no definite generic answer.

We don't want it to do everything for everybody. This means that we might decide against incorporating a new feature.

The guidelines encourage a contributor to properly discuss a major improvement that brings a new idea, or could have

If you make it case-by-case then its always an arbitrary decision of person or persons leading to situations that contributions from one person can fly while similar contribution from other person may not go, because that person is not familiar with maintainers or doesn't have a proper communication skills/channels to reach out valid people who can push things over. Above statement also does not outline what are most needed contributions and what are most common cases to refuse donation and what a complete answer could be. If whole statement is silence over months, its not a valid answer. Also, if there is an group of people who is supposed to drive project (openHAB Architecture Council (AC) serves the community by identifying and tackling any issues that hinder openHAB’s continued technological success and innovation, widespread adoption, and future growth), where are the ideas or issues which will increase "technological success" and "innovation" ratio? Well there are none cause we keep hearing that "AC" can't do anything, as it can't dispatch any resources to work on own ideas. It is especially visible in core. Above institution function is currently limited to an "architecture court". It doesn't seem very convenient for third party contributions in core if you get all these conditions together.