186 replies to this topic

[athoik]

I would agree if the complete code of enigma2 was perfect. But it is not. There are many sections that the code is far worse than at least the original JESS patch.

I did not see any patch to make existing code better. Anyone that has patches that improves current code, they get merged.

Why continue adding code that will need many changes sooner or later?

 

And if you are reviewing code, you don't reply as "quality of the code is terrible". Point to certain sections of the source that need to be changed in order to get committed.

I did point to certain sections of the source, I also fix some of them on my jess branch.

There is nothing wrong saying code needs finetuning. We are making a hobby here, not a job that has deadlines and you commit whatever just to make customers happy.

 

We have become so much bureaucrats that we had to talk for days (or maybe weeks?) to just change a default debug log level from 4 to 3.

Yes, although we said to promote some eDebug to eLog 5,6, nobody offered a patch.

Not to mention that a bug appeared in CI after changing to log level to 3. I've seen again no help.

So we did a change (that was prerfect for some people) to make them happy and then WE had to find the problem ...

Edited by athoik, 13 April 2016 - 09:33.

[littlesat]

@Athoik,

 

Do you have a banch we can merge in a jess-test branch? So we can somehow build and work together on this topic? (sorry when I previously missed it)...

 

Not to mention that a bug appeared in CI after changing to log level to 3. I've seen again no help.

Do we still need to merge something? It can be that we missed it....

Edited by littlesat, 13 April 2016 - 10:36.

[athoik]

Yes I have but only the Vu-Jess commit.

I guess we should start cleaning the OpenPLi jess branch.

I will start soon.

Edit. Regarding the CI, the last commit from betacentauri should fix it.

Edited by athoik, 13 April 2016 - 10:41.

[littlesat]

Thanks... are you also capable of testing?

[athoik]

Thanks... are you also capable of testing?

Not yet, maybe in summer time i will be able for field testing. I guess clenup will be done till then.

[malakudi]

At least the openPLi team arrange the level 3/4 and more possibility in a structured way why firstly eDebugs were only suggested to commented out.... 

 

At least I could re-offer a new test-jess branch so who can develop (build images) can build and test so we have at least a platform for testing and improvements. I suggest that is a good step to begin with... 

 

I agree using 'terrible' here in this content is likely not the best expression from my side... and this is something I do not really mean that way.... Especially I'm also a coder so I'm aware it took a lot of time to implement...

 

Please note it has nothing to do with 'bureaucrats policy'... 

 

Yes, we did very well with the structured way and then we did nothing, for weeks. Till chris exploded again and we started talking and talking. We talk too much, we act less. So what if a bug was introduced? We can always revert. Many times the build was screwed by bad commits, why the commits from outsiders have to be perfect? I still don't get it.

 

@athoik: The JESS code (at least the original one which is NOT from VU+ btw, it is from dvb-adenin like the rest) has been accepted to all other images except OpenPLi. We are either too elitists to accept such patches or we have some other problem. For sure, there is a problem accepting code from outsiders, which is something I don't like.

[athoik]

@malakudi,

I guess it is already said that when OpenPLi 5 will be out there will be two flavors of OpenPLi.

The beta and experimental (or sid). That will speedup development and testing.

Breaking installation almost weekly is not good... and that will change.

So patience...

[arn354]

There is no doubt if different people look on something - they look differently on it.

There is also no doubt that code is improvable. But that's the case in almost every part of code you look into and you might find another way to write it.

[Huevos]

At least the openPLi team arrange the level 3/4 and more possibility in a structured way why firstly eDebugs were only suggested to commented out.... 

 

At least I could re-offer a new test-jess branch so who can develop (build images) can build and test so we have at least a platform for testing and improvements. I suggest that is a good step to begin with... 

 

I agree using 'terrible' here in this content is likely not the best expression from my side... and this is something I do not really mean that way.... Especially I'm also a coder so I'm aware it took a lot of time to implement...

 

Please note it has nothing to do with 'bureaucrats policy'... 

On one hand PLi asks for patches and on the other hand nothing is good enough.

 

Even merging a couple of lines of code so Satfinder can handle FBC tuners correctly has been rejected.

 

With the JESS/Unicable code months of testing and refining have gone into it and now PLi wants to start again from scratch.

 

Like Athoik says this is a hobby. If each team spends weeks/months continually reinventing the wheel when another team has already done the work we will never have time to do anything progressive, which after all is why people use our software.

 

The other problem I see with OpenPLi is there is no development branch. Code is never properly tested and it goes straight to the public domain. This is a severe impediment and makes the OpenPLi team reluctant to merge anything for fear of it breaking the public image.

 

If you look at OpenViX, for example, code goes in the Dev branch and all team members and beta testers can try it. Builds of that branch are done daily. Then, every so often, code is merged into the master branch and built for the public image. Only bug fixes go directly to the master branch.

[WanWizard]

Huevos,

 

We are very aware of that. We have a development branch (master-next), but no public images are generated from it, only some "home-brew" images, so testing is limited because you can't cater for all situations.

 

We're busy with purchasing / setting up a new infrastructure so we can have stables and expirimentals, and can develop (and make mistakes) without impacting the greater public. We didn't have the means to to this earlier.

 

Expect this to go live in about 6-8 weeks, which will hopefully coincide with the release of OpenPLi 5.

[Huevos]

I was talking about E2, not core. All commits go straight to master it would seem.

[WanWizard]

The enigma2 repo has a master-next too. I can't really comment on what goes where, it probably has to do with the lack of an expirimental or development build.

 

I completely agree with you that you should only ever commit into your develop branch, and backport fixes (if you use two branches), but I personally use git-flow for my projects, which addresses all these issues.

 

In a professional environment that is a no-brainer, but in a "hobby" environment it seems to be a bit of a challenge sometimes...

[littlesat]

I'm afraid the real clue isn't yet understood.... 

 

I did made a next jess branch based on Huevos his patch so some who could build an image could test. There was response of slower zapping... And this is a symptom/side effect we should avoid... When I verify our git now it seems the branch did disappear (when it was from my side unintended). I did hope this could be used for improving the current JESS implementation - but this did also not really work-out.

 

As far I understood ARN356 made a fix for the slow zapping by the switching option between traditional and reliable.

 

I'm willing to re-merge all JESS stuff to our enigma2 in the next-master branch. But while doing this I hope everyone could listen to each other comments helping to improve it... I'm also willing to help here... Only then we all benefit from it. 

 

When it is in the next branch it will also be in near future in our test images...

 

And please note that when JESS is getting cheaper and FBC tuners became more common... we still have to implement JESS somehow....

[arn354]

When I verify our git now it seems the branch did disappear (when it was from my side unintended).

 

 

As mentioned before branch/tree is still there - https://github.com/O...igma2/tree/jess

And i did a pullrequest to apply the last changes.

I am also willing to contribute improvements there - if i am capable of and if the decision is made to improve from that code base further on.

Edited by arn354, 13 April 2016 - 13:31.

[littlesat]

oeps.... I did oversee that.... 

 

i just did merge your new two commits....

 

Probably we should also consider to simply put it in next master

Edited by littlesat, 13 April 2016 - 13:55.

[littlesat]

I just synchronized (merged) the whole JESS stuff into the JESS branch... and the hole JESS stuff in the next-master branch.... (when it really hurts the next-master branch I can still revert it).

 

Now the cleanup could be started....

Edited by littlesat, 13 April 2016 - 14:23.

[arn354]

ups - then close the pull-request  and use the attached patch instead.

 

Attached Files

•  JESS_improve_NimManager_code_as_suggested_by_athoik.patch   3.06KB   6 downloads

[littlesat]

And I started to commit my first suggestion...

 

Please note the "and 1 or 0" could be also removed here when it is changed in cpp to booleans...

[littlesat]

I'm afraid I already merged it... Please offer a fix....

[arn354]

patch from above still applies or pullrequest is mergable.