772 replies to this topic

[WanWizard]

[Persian Prince]

https://github.com/OpenEnigma2 is up with the first version of the general module.

 

Other teams could ask for invitation.

 

I'm sending PRs to PLi metas regarding some needed variables.

[WanWizard]

I'll have a look at it after we've released 8.0, currenty I'm trying to keep develop stable to make last-minute bugfixing easier.

[Huevos]

https://github.com/OpenEnigma2 is up with the first version of the general module.

 

Other teams could ask for invitation.

 

I'm sending PRs to PLi metas regarding some needed variables.

So you have opted not to go for a neutral repo.

[WanWizard]

We can always rename it if someone comes up with a better name. Github will automatically alter upstream links of any forked repo's.

[Abu Baniaz]

May I ask what is purpose of distro specific stuff? Surely those things should come under the remit of " how a distro creates/supplies the data is up to them"?

[Persian Prince]

 

https://github.com/OpenEnigma2 is up with the first version of the general module.

 

Other teams could ask for invitation.

 

I'm sending PRs to PLi metas regarding some needed variables.

So you have opted not to go for a neutral repo.

 

 

The new organization doesn't have any other repo or extra member, what possibly more do expect?

[Huevos]

https://github.com/OpenEnigma2 is up with the first version of the general module.

 

Other teams could ask for invitation.

 

I'm sending PRs to PLi metas regarding some needed variables.

Just out of interest why was it necessary to have "openvision" or "ov" in every single variable and function name?

[Persian Prince]

May I ask what is purpose of distro specific stuff? Surely those things should come under the remit of " how a distro creates/supplies the data is up to them"?

 

Should we document what are we doing with our specific things? Clearly a big no.

 

As long as we keep it out of everyone else's compiling we're good to go.

 

Nobody would maintain our code and our code won't harm others.

 

The reason the code is public for everyone is to give others the opportunity to study/use the code otherwise it's easy to keep things to ourselves and don't let pirate teams come up with them.

 

Soon we'll see those teams on other forums talking about "being genius"

[Persian Prince]

 

https://github.com/OpenEnigma2 is up with the first version of the general module.

 

Other teams could ask for invitation.

 

I'm sending PRs to PLi metas regarding some needed variables.

Just out of interest why was it necessary to have "openvision" or "ov" in every single variable and function name?

 

 

OMG! O M G!

 

It's like Deja Vu each time!

 

If the names are this much important to you I suggest give it up and don't participate in this topic as it's not for people who just see in front of their nose and not the future.

 

You don't have a Vision you don't get what's a prototype, those are just function names and won't affect the outcome.

 

This is exactly why I asked for devs who understand how a kernel module works so I won't waste my time answering abnormal questions.

 

I'm done answering posts about names, grow up please.

 

And if you want to start your answer with writing "LOL" again, save it as it's boring.

[Abu Baniaz]

I don't know exactly who/what you mean by "our". What a Distro does with their code is up to them and should stay on their GIT. The "one proc for all" design should be just about the procs. Any plugin author/distro can just use what is there or request new functions when required.

 

The shared repository should avoid distro specific values. An implementation of "if this, do that, otherwise do the other, else do something else" is a bad design. we then go back, if manufacturer 1, or manufacturer 2, blah blah blah. 

[Persian Prince]

I don't know exactly who/what you mean by "our". What a Distro does with their code is up to them and should stay on their GIT. The "one proc for all" design should be just about the procs. Any plugin author/distro can just use what is there or request new functions when required.

 

The shared repository should avoid distro specific values. An implementation of "if this, do that, otherwise do the other, else do something else" is a bad design. we then go back, if manufacturer 1, or manufacturer 2, blah blah blah. 

 

Don't you get this the prototype not the final code?

 

We have our own https://github.com/O...envision-module

 

We're not even using the new repo, it's for study and test.

[WanWizard]

It is technically not handy to have to make two modules, one for generic and one for image specific nodes.

 

Having said that, what I think should happen is put the image specific code in a separate c file. So provide a dummy / empty file in this repo (so the module compiles without any added image specific stuff) but is allows the image builder to override the empty source file from the recipe.

[Abu Baniaz]

Surely any image specific files should be created by the image and not be included in the openhal? The openhal should be universal IMO. 

[Persian Prince]

It is technically not handy to have to make two modules, one for generic and one for image specific nodes.

 

Having said that, what I think should happen is put the image specific code in a separate c file. So provide a dummy / empty file in this repo (so the module compiles without any added image specific stuff) but is allows the image builder to override the empty source file from the recipe.

I know what's their problem, they have problem with our name in this module and I'm happy to take all the extra code out and apply it as a private patch.

 

If you see they don't improve a single line of the code or finding any problem as all they see is our name.

 

It's no longer fun for me to work on this project, I'll sent the PRs if you wanted merge them I don't care anymore.

[Abu Baniaz]

 

I don't know exactly who/what you mean by "our". What a Distro does with their code is up to them and should stay on their GIT. The "one proc for all" design should be just about the procs. Any plugin author/distro can just use what is there or request new functions when required.

 

The shared repository should avoid distro specific values. An implementation of "if this, do that, otherwise do the other, else do something else" is a bad design. we then go back, if manufacturer 1, or manufacturer 2, blah blah blah. 

 

Don't you get this the prototype not the final code?

 

We have our own https://github.com/O...envision-module

 

We're not even using the new repo, it's for study and test.

 

 

Your response does not make sense. Please rephrase.

 

Everybody understands the difference between prototype and final product. Not that there is a final product with an open ended project that has version control.

[WanWizard]

I know what's their problem, they have problem with our name in this module and I'm happy to take all the extra code out and apply it as a private patch.
 

If you see they don't improve a single line of the code or finding any problem as all they see is our name.

 

It's no longer fun for me to work on this project, I'll sent the PRs if you wanted merge them I don't care anymore.

 

I hope you'll reconsider, as I think we're on the right way. As you say, it's a first attempt, it needs lots of fine tuning and input from everyone

 

I don't have time to look it it in detail, and propose improvement, until after 8.0-release, that currently takes up the little time I have...

[Huevos]

I don't understand why you are getting so irate. I just want to know why the variables and function names all contain "openvision" or "ov". What purpose does that serve in increasing the readability of the code? To me it is just a cruft that makes the code harder to read.

[Persian Prince]

Make it easier to read/work then as I don't care, there's a public git there which you can do whatever with it.

 

I'm not a developer I'm not a contributor I just like what I've done and the result is fine to me and we're using it in our projects.

 

This discussion is boring as hell as I have to do everything and answer about simple names all the time.

 

I'm sendig the last PRs for PLi's metas and then I'm out of this for good.

 

If you got to the final product pin me on github so we follow otherwise I see no other reason to participate in this topic.

 

Seems some people knew something from the start as they didn't post a thing.

[WanWizard]

I've seen your BSP PR's.

 

This is exactly why I have always said that implementation is and should be specific to each image.

 

I definitely don't want BSP changes, and BB variables in all sorts of places. We have a strict separation between the vendors responsibility and our responsibility, and I would like to keep it that way.

 

So please close them again.