72 replies to this topic

[IanSav]

Hi,

 

Thanks for the explanation on disabling post editing.

 

Does anyone have any comments or feedback on my main post about code contribution?  Will outsider posts get a better / more fair hearing?

 

Regards,

Ian.

Edited by IanSav, 16 March 2018 - 22:30.

[WanWizard]

I think it is difficult to get a generic answer. For me personal, code is code, I don't care who contributes it.

 

But my knowledge of the internals is limited, so often I have to pass it on to someone else.

[IanSav]

Hi,
 
To bring this thread back on topic...
 
Huevos recently built me an active OpenPLi image with which to develop and test my code.  This appears to work well.  I reworked a significant development to include OpenPLi.  This development was a refactored and improved Setup.py that is faster, has new features and has the ability to run on multiple Enigma2 images *without* any code changes.  (This was done to make inter image merges significantly easier.)  I also wrote some comprehensive documentation on the usage of Setup.py and associated skin screen elements.  The code was specifically rewritten to fully support OpenPLi, OpenViX and Beyonwiz images *without* modification.  This new code was significantly tested and *no* issues for any image were detected.
 
I submitted this code to the OpenPLi repository two days ago (https://github.com/O...igma2/pull/1426).  I specifically asked that if any issues were detected to notify me immediately so I could offer prompt attention with a view to resolving any issues.  The code was accepted and merged by Littlesat without issue.  One day later all the code was reversed without any explanation or comment other than a note saying that code not specific to OpenPLi not unwanted!  OpenViX was specifically mentioned for not using the menu path system developed for OpenPLi.  (My code supported all version of the menu path system.)
 

Sorry IanSav for reverting these merge requests... See here https://forums.openp...oposal/page-155 from post 3095
I'm afraid as it is now it makes the things complicater. I still think there are good suggestions in between... but e.g. the boxbranding part is not done as we prefer we need to make it as clean as possible
When you look at all of it above it adds a lot of code without any real good added value as far I can see... I do not think we need to make our OpenPLi code VIX and OpenPLi compatible.... I think we just need the stuff for OpenPLi and all OpenVix specific stuff can get out. E.g. for the menu path stuff OpenVix might better consider to appoach the OpenPLi way of doing it as this avoids a lot of changes in other code and plugin to get the path there... Then also this code gets cleaner...
Sorry as I know how much time it took for you. Better next time discuss it on the forum before making merge requests...

 
I have asked for explanation on why the code was rejected and after more than a day later my requests for explanation have gone unanswered.  In the initial rejection, quoted above, I was give a link to a closed area of the forum.  What is the point of providing links to a developer area of the forum if external developers are denied access?  Further, how is a developer to discuss proposals if they are denied access to the developer areas of the forum?
 
Does anyone at OpenPLi still want to complain that external developers never submit code to OpenPLi?
 
I am yet to be given any explanation for this disrespectful treatment and handling of my code and documentation contribution.  In the light of the comments and thoughts expressed in this thread I felt it appropriate to report on the poor and insulting way my contribution to OpenPLi and the Enigma2 community at large has been handled.
 
Some points for follow up:

• I welcome feedback on why my submission was rejected.
• I would also like to know if the closed developer area of the forum is going to be opened to *any* developers.
• I would also like to know if trying to work with OpenPLi now or in the future is simply a waste of my time and effort.

Regards,
Ian.

[littlesat]

first you need access to that link. I hope you’ll be invited soon. I tried to explain things on GitHub. We prefer to keep code as clean as possible and then make code compatible for three different images does not help - it’s a burden...

Next time better post your ideas and thoughts here on the forum before creating something solo for yourself. Then a whole team can help you and we have a chance to get it even better...

Edited by littlesat, 8 April 2018 - 11:29.

[IanSav]

Hi,

 

The compatibility code I wrote, which works very well and shouldn't require much, if any, maintenance is not a burden.  Making code easier to merge removes a significant burden for MANY people!  If my compatibility code was seen as undesirable then why weren't the very few lines of code removed and the rest of the submission accepted?  Why wasn't this issue raised before the code was merged and then reverted?  What was done makes me look very bad / incompetent to the development community!

 

If I was contacted and asked to remove the compatibility code I could have done that without any issue.  I wasn't contacted or given an opportunity to adjust the code.  It is poor form to reject a pull request and not provide an explanation *with* the rejection.

 

EDIT: I *STILL* can't see the developer thread mentioned in the rejection post!!!  Still no reasonable explanation for the whole pull request being rejected.

 

If OpenPLi really wants external developers to contribute code back into OpenPLi then there will have to be acceptance that some things may be done differently.  Different is NOT wrong, it is just different.

 

I am still to be given any assurances that external development is welcomed by OpenPLi.

 

Regards,

Ian.

Edited by IanSav, 8 April 2018 - 11:36.

[Taapat]

I wanted to say just my personal thoughts about the last reverted commits.

But these are just my own thoughts, and this is not the opinion of the OpenPLi team.

 

1. For me is not acceptable boxbranding staff in enigma.

On OpenPLi is always trying to make exceptions for options not for the receiver. Therefore boxbranding has never been used in enigma.

Of course in SystemInfo there are many exceptions for the receiver that are masked as exceptions to the options, but they are in one place.

 

2. I do not think that the good argument is that you need to change something because it has other images.

It seems to me that a good argument is that it works more optimally, faster, spares less resources, eliminates possible errors, the code is better readable or conforms to the standard.

 

I support the ability to read all the topics for developers. I remember how I was sometimes annoyed by the fact that your commit is denied by pointing to a topic that you can not read.

But I understand that you will be invited soon.

Edited by Taapat, 8 April 2018 - 11:41.

[IanSav]

Hi,

 

Also, why was this commit reversed: https://github.com/O...igma2/pull/1424 ?

 

There is no compatibility code in there.  It simply made ActionMaps and HelpableActionmaps easier to use interchangeably.

 

Regards,

Ian.

[IanSav]

Hi Taapat,

 

 

I wanted to say just my personal thoughts about the last reverted commits.

But these are just my own thoughts, and this is not the opinion of the OpenPLi team.

 

1. For me is not acceptable boxbranding staff in enigma.

On OpenPLi is always trying to make exceptions for options not for the receiver. Therefore boxbranding has never been used in enigma.

Of course in SystemInfo there are many exceptions for the receiver that are masked as exceptions to the options, but they are in one place.

 

2. I do not think that the good argument is that you need to change something because it has other images.

It seems to me that a good argument is that it works more optimally, faster, spares less resources, eliminates possible errors, the code is better readable or conforms to the standard.

 

I support the ability to read all the topics for developers. I remember how I was sometimes annoyed by the fact that your commit is denied by pointing to a topic that you can not read.

But I understand that you will be invited soon.

 

 

1. The boxbranding code is disabled on OpenPLi.  The OpenPLi equivalent doesn't work properly.  It misidentified my box.  That is why the OpenPLi equivalent call was commented out.  If I couldn't get a successful test on my machine I didn't want to inflict the problem on others.  If the OpenPLi box identification code worked properly then perhaps others might use it.

 

2. Did you read the pull request?  Did you see what it fixed and what it improved?  I suggest you read the detailed commit notes and the user manual I provided and then consider retracting this point.

 

For the record, this code was initially written to enhance OpenViX and Beyonwiz images.  It has not yet been submitted ANYWHERE.  The OpenPLi submission was the first public revelation of the new code.  I added OpenPLi support as a gesture of good will to show that non OpenPLi developers could and would submit improvements to OpenPLi.

 

The way that *ALL* my OpenPLi pull requests have been handled shows that OpenPLi likes to complain about external developers but when one tries to work with OpenPLi his efforts are unconditionally rejected!

 

3. OpenPLi should acknowledge that they feed lots of code to other images.  Making it harder, just for the sake of being different, is not being a good ambassador for Enigma2.  My code showed that it is easy to make improvements to Enigma2 without deliberately making code merging with other images more difficult.

 

Regards,

Ian.

[betacentauri]

Reverting your code doesn’t mean that we don’t want any contribution from other developers!
Why all? I don’t know but maybe there was no time to fix the code or there are issues that have to be discussed how to do it. Maybe read the comments in the commits like here (https://github.com/O...c4877fb49b631e7) and start a discussion with littlesat, ims, taapat, ... why it’s a good idea to do it in this way.

[Taapat]

1. If you make tests on a non openpli enigma, you can change what you need and use boxbranding.

But why offer this in openpli enigma, even if it is not used there?

 

2. First, I check commits after they merged in develop.

And in many commit I see the following comments:

Add HelpableNumberActionMap to OpenPLi to match OpenViX and Beyonwiz images...
For OpenViX and Beyonwiz this change allows...
Add Beyonwiz and OpenViX footnote support code...

And as others  already point it, then the impression is that it's done only to be like other images.

 

In PR your description is good, without reference to other images.

 

I am sure that the changes you are proposing are good, but they should be slightly revised.

 

I do not consider myself an enigma2 or python expert, so I think you do not have to spend time trying to prove something to me.

I just wanted to say what I do not like in these changes, but I'm not not merge and not revert something.

[IanSav]

Hi Betacentauri,

Reverting your code doesn’t mean that we don’t want any contribution from other developers!
Why all? I don’t know but maybe there was no time to fix the code or there are issues that have to be discussed how to do it. Maybe read the comments in the commits like here (https://github.com/O...c4877fb49b631e7) and start a discussion with littlesat, ims, taapat, ... why it’s a good idea to do it in this way.

I think I have made 4 or 5 pull requests to OpenPLi.  Do you know how many have stayed in OpenPLi?  NONE.  As far as I am aware none of the code was faulty or caused any issues.  They were just changes that OpenPLi don't understand or want.  There appears to be no regard for what improvements they may have offered to others.

 

There is no place to interact with OpenPLi developers as that area of the forum is closed to outsiders.

 

Regards,

Ian.

[IanSav]

Hi Taapat,

 

So there are a few lines that you selectively quoted.  What about the hundreds of other lines I wrote outlining the improvements to OpenPLi users?

 

I don't understand why OpenPLi is so scared about interacting with other images.  Talk to us, many of us are friendly.  Well we try to be friendly but OpenPLi sure makes that VERY difficult! 

 

Regards,

Ian.

[Erik Slagter]

I wanted to say just my personal thoughts about the last reverted commits.

But these are just my own thoughts, and this is not the opinion of the OpenPLi team.

 

1. For me is not acceptable boxbranding staff in enigma.

On OpenPLi is always trying to make exceptions for options not for the receiver. Therefore boxbranding has never been used in enigma.

Of course in SystemInfo there are many exceptions for the receiver that are masked as exceptions to the options, but they are in one place.

 

2. I do not think that the good argument is that you need to change something because it has other images.

It seems to me that a good argument is that it works more optimally, faster, spares less resources, eliminates possible errors, the code is better readable or conforms to the standard.

Exactly that!

[IanSav]

Hi Erik,

Exactly that!

What point are you trying to make? Is it constructive of the discussion?

Regards,
Ian.

[betacentauri]

Please calm down a little bit. I think we are also friendly . It’s most likely (I didn’t look at your patches as I’m not the best python coder) not faulty code why it was reverted. I guess littlesat first thought code is looking good but later there were several comments about it. Maybe because of lack of time he reverted everything (I didn’t speak with him).

[IanSav]

Hi Betacentauri,

Please calm down a little bit. I think we are also friendly .

It isn't looking very friendly from my perspective.  As a result I am finding it very difficult to stay calm.

I specifically invited discussion and collaboration but in don't seem to be getting much in return. All I seem to see is "Not Invented Here" excuses or "It was always done that way."  or "We don't care about other images."  Not reasonable or informative to form a proper discussion.

 

Regards,

Ian.

[Erik Slagter]

Most probable cause for a revert is that it simply doesn't work, for example GSOD's. In that case, we revert FIRST and discuss LATER. We can't have a broken enigma in either rc or develop builds.

 

It does not mean "the contribution is crap" or "the idea is nonsense". It means it's not suitable for inclusion in this form.

 

Ideally a discussion should start about what needs to be changed to make the patch acceptable. Ideally the contributor should see the problem himself, create a fix and contribute it again.

 

Sometimes it's not immediately clear what's the problem (besides the solution) and then some discussion could take place.

 

Last but not least, contributions are appreciated, that does NOT mean we are required by any means to accept ALL contributions!

[IanSav]

Hi Erik,

 

I ran tests of the code on OpenPLi myself and I had another tester in Europe.  No issues were detected.  In the pull request I specifically asked to be contacted if there were any issues so I could promptly apply any required fixes.  I was NEVER contacted.

 

I am yet to be made aware of any technical faults in my code.  To me this seems more political than technical.  The derogatory comments about OpenViX and Beyonwiz only support my assertion.  If OpenPLi wants to be the only image then actively support all the hardware, broadcasters and conditions that exists all over the world!

 

Regards,

Ian.

Edited by IanSav, 8 April 2018 - 13:16.

[littlesat]

It is not only about it’s working... and you could help yourselfe to start a discussion on the forum instead of pushing a merge request and then being disappointed when Tinus rejected and/or mergen and then reverted...

[IanSav]

Hi Littlesat,

It is not only about it’s working... and you could help yourselfe to start a discussion on the forum instead of pushing a merge request and then being disappointed when Tinus rejected and/or mergen and then reverted...

There is no need to use the forum.  No need to talk *about* me hidden in the forum, you could talk directly *to* me via the Git repository where everything could be kept together and in context.

 

All of this could have been handled in the Git pull request *before* the merge.

 

Regards,

Ian.

Edited by IanSav, 8 April 2018 - 13:37.