New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EOL? #1629
Comments
Should OpenPLi switch? Is it, and will it stay compatible? |
It’s up to you. I have stopped working on version 1.x someone else can take over or you switch to version 2.x But version 2 is different. Especially for branding. |
Ok. So I am right in my observation that OpenWebif is no longer open, but is now OEAwebif. |
Which is a pain because it is explicitly and purposely designed to ignore our situation, so we can't implement it. |
This is wrong. |
No.The word Open comes from open source not from OpenPli. By the way. Most of the distros have switched to version 2. |
I don't know what you mean by this. For more than 10 years we have been trying to persuade OpenPLi implement some form of information system (branding, boxinfo, etc) but OpenPLi team just pontificate and tell us it is unnecessary. We offered many different solutions but none were good enough. And the OpenPLi team itself has done no work of their own in this respect. Do you really expect jbleyel to go on and on maintaining code that he don't believe in just to appease people who want to drag there feet? So he has just left the version that is impossible to maintain for those who don't want to keep step with the other distros and moved on to a new cleaner version without the hacky workarounds. We too at OpenViX had to make a few changes to be with OpenWebIf version 2.0 but that's life if you want to be compatible with newer software and take advantage of the benefits. There is nothing stopping OpenPLi implementing the code that is needed to be compatible with OpenWebIf version 2.0. OE-Alliance-Core, openatv and openvix are all open source. The code is there for anyone that chooses to implement it in their own repos. |
Bull cookies. We're running around in circles. I've explained over and over again that we CAN'T implement the system as currently designed, as it REQUIRES a one-on-one between STB model and MACHINE, which OpenPLi doesn't have, doesn't see the need for, and doesn't want to implement. And it makles me sick that people like you then try to shift the blame to us. Especially since you're one of the people we've invited into our kitchen in an attempt to find common ground in these kind of design decisions. This fact has been ignored time and time again, including by you @Huevos, making it very difficult (if not impossible) for us to implement the current boxinfo design with the static enigma.info file. It is not us we don't want to implement, it is OE-A who very selfishly can't be bothered to cooperate and take others into account. My point was that OE-A has invented something that only works for OE-A (based images), and by moving to make a a previously fully open project to depend on that, means it is no longer open, it is OE-A specififc. And OpenVIX is OE-A, which makes your arguments moot. |
Don't shoot the messenger. I am one of the few non PLi members who has gone out of my why to bring new exiting features to PLi as well as continual bugfixes. The truth is jbleyel is the developer and it was his decision to fork it. OE-A members choose which version they use. No one is forcing anyone to do anything. As far as BoxInfo goes, yes it requires one-to-one, so if PLi's images aren't one to one, use a one-to-one name in BoxInfo. It will work. I even made a BoxInfo for PLi, complete with all data but it got rejected. |
I have no problem with BoxInfo in itself, I'll trade a global list for an immutable object every day of the week. The problem is its source, we can't create the enigma.info file that is not only at the basis of BoxInfo, but is also checked directly at lots of places in the code. We simply don't have the required data at compile time. There is absolutely no justifiable reason to abandon E2OpenPlugins, and move to an oe-a repo, other than an attempt to close the door for all non-oe-a images, irrespective of the boxinfo discussion. It could have been another branch of the current repo, it could have been another E2Open repo, but it was decided not to. Which means we will be forced to implement every OE-A whim just to remain compatible with something that was Open. Please don't pretend this is new, it is OE-A's signature, fork everything including the kitchen sink, and then make sure it is no longer compatible with the original to prevent others (i.e. OpenPLi) from using it. |
p.s. it is not only BoxInfo, there are more OE-A specific dependencies, for example with information about RC's. |
That isn't true. On version 2.0 the remote image is virtual.
So apart from branding what else is not compatible? |
Permanent forking is the beginning of the ending of an opensource project and working together. It always happen when some egos cannot archive condenses and then prefer steal the project by forking it. |
You all miss the point.
|
I think you missed mine. You started it as an OE-A specific project, in an OE-A specific repo, with OE-A specific dependencies. Which happen to be the environment you contribute to in general. While the original OpenWebif was really open and available / usable for all distro's. It is a generic OE-A trend since its conception: fork everything, then make the fork incompatible with the original and the distro's the original is used on. |
This is wrong. I have only use the GitHub space of OE-A.
Version 2 is not closed.
This is also wrong. Again!! I have stopped working on this repro. |
! Please note that this version of OpenWebif is no longer in development !
Log a feature request for OpenWebif v2 instead:
https://github.com/oe-alliance/OpenWebif/issues?q=is%3Aissue
@wedebe @jbleyel
Why the above? Why no longer "E2Open" but OE-Alliance? Why are image builders using this version not informed / consulted?
The text was updated successfully, but these errors were encountered: