1748 replies to this topic

[IanSav]

Hi Littlesat,

 

With each commit you made your name is on the commit and stayed on the history.... this should be sufficiant I suppose... no need at all to add it in the code...

 

As I mentioned above, some people are bypassing the Git commit histories by simply copying and pasting code and not cherry picking original commits.

 

Regards,

Ian.

[littlesat]

Yes that happens.... then without mentioning the ‘source’ or based on or a thanks this is not nice. Sometimes it happens by accident... I suggest this is not a real issue. You can always prove it as the history is showing dates. Some times thinks happen within the open source community. It is not polite and helpfully to add your ‘ego’ in the code.... that is even more brute and lowers you to same or even lower level than those that (by accident forgot) to thanks you...

Edited by littlesat, 17 April 2021 - 06:14.

[IanSav]

Hi Littlesat,

 

Seems you are also stuck on the "ego" train.  Just browse the GNU sources and then criticise all those authors for exposing their "ego"s by putting their names to their code.

 

Never mind, this distraction has gone on for much longer than I expected or intended.  I do not put my name on communal code but I accept that some people may wish to do so.  I have no intention of objecting to such a practice.  It is totally harmless and, as I asserted, can be very helpful.

 

I now expect all the comments about stolen code and failure to acknowledge authors to also stop.  I hope this discussion has alerted everyone that the practice of taking code and hiding the author is bad practice and should not be done.

 

Regards,

Ian.

[littlesat]

Should I start to put my ego in enigma2? You’ll wonder as my name will be anywhere in the code with mentioning do not remove these credits!
Better say and get thanks!
This time pp thanks for your PEP script!

Edited by littlesat, 17 April 2021 - 07:15.

[betacentauri]

If someone removes names from git history, he can also remove the names in the source code...

Do you want source files which have 200 lines with “This is copyright by x, this part has another copyright, and this was written by xyz” and then starts the real source code? Or better every 2-3 source lines you find a 1-2 liner with “I made this and have copyright on it”?
Would be “great” for readability and maintaining the code.

I know VTi stole my code. Am I happy with it? No. Can I do something against it? Not really. Adding my name in the source doesn’t help. Only “solution” is to stop supporting open source projects. Is that the way to go? For me I can say no. I live with it.

[littlesat]

VTi is a team that does not add any value at the opensource community... So be it! The only thing that can be done is that the community ignore them.... but as long there are users they somehow aren’t ignored...

I’m for example not happy that my Hotkey code is forked.... not that it is forked but the way it is forked as the py files are renamed to buttonsupport or something like this. This is a factor that does not promote merging/cherry picking..... I mentioned it and ATV did change the name back to hotkey and not the source files are still renamed and Vix did totally nothing with it.... but what can I do... only mentioning it and hope!!! And live with it and continue to promote the nice thing that is called opensource... and accept the risk someone can take your code put it In a closed source blub (steal it)... or modify it such a way that you cannnot get improvements in an easy way.... and beside accept just think I’ll try to continue doing better....

Edited by littlesat, 17 April 2021 - 08:32.

[Huevos]

@Littlesat, what can I tell you? Enigma2 is a friendlier place than 10 years ago. Now when a file changes name we try to do it together.

 

10 years ago it was difficult to get PR's accepted into PLi and that is one of the major reasons why OpenViX and and OE-Alliance got created.

 

Even today stuff gets talked to death before getting acted on (if at all), and people just get bored and do their own thing in their own distro.

Edited by Huevos, 17 April 2021 - 11:09.

[littlesat]

Yes.... OpenPLi tries to remain some quality on the code.... And this means resistance.... and this means someone who is not patience will solve the issue by forking the stuff....

 

I remember years ago the permanent timeshift plugin. Someone tries to integrate that one into enigma2. But with a seperate cpp file as so.... we did not except that as we at least want to have that integrated and in addition I remember at that time I suggested to remove the complete timeshift code from enigma2 and arrange instead that a 'normal' recording should start that is also viewable as 'timeshift'... so a lot of code could be removed by some restructuring. 

That restructuring did never take place (timeshift works, permanent timeshift inbetween solved in a different way did not have real priority).

Due to unpatience, getting angree a commit or merge request was not excepted, years ago OpenVix was born ...

 

We had that several times... e.g. the Jess stuff. OpenATV did support it with an extreem big 'Adenin' patch which they excepted. An extreme long time we did also support it with less and streamlined code than it was before - also with a lot of help from othner teams/images, especially from the OpenViX team that time (and still some 'Adenin' code from the unicable time can be cleaned up and/or is not required). It sounds like 'elswere' they are going for "it just works" while "we" are trying to keep some Q...

 

Stuff get talked to death not because they are talked to death, but because there are people that cannot come to conceses. It is their way or nobodies way. An example here is the "boxbranding" stuff. Those who create the existing one for OE-A are convinced that their solution is the most optimal solution so are somehow not willing to change this resulting in the fact that it is currently a silenced never ending story.

 

I would "say" this is the counterpart from an opensource project being forked due to someone does not listen to comments, arguments, advices when a merge is not accepted by a 'core' team... and as reaction instead of doing some additional work (which could also be give good arguments) fork the stuff and start a 'new' project...

 

Most times it is a challange to work together. Enigma2 is an example of it

 

Regarding my 'Hotkey' frustration I had the feeling that someone did rename it to ButtonsSelection.py or something like that on purpose... to somehow 'block' cherry picking and merging... Maybe not the good idea as it also could be that that dev thought it is a 'better' name and for that reason it was renamed... 

Edited by littlesat, 17 April 2021 - 11:45.

[WanWizard]

As I mentioned above, some people are bypassing the Git commit histories by simply copying and pasting code and not cherry picking original commits.

 
Those people willl also remove any remarks about copyright in the code, so what exactly is your point?

 

As any psychologist can tell you, anyone is driven by a combination of

• fun, you do something simply because it is fun, you like doing it
• reward, you do something because of the reward attached to it, whether it be money or something else
• status, you do something because it makes people recognise you, look up to you

Assuming none of the contributors makes money of it (history has shown that is a possibility), it is either done for fun or for status.  And the only reason for wanting to stick your name to everyhing is status. "look at me, I did this". For the same reason these people are angry when their name is removed, because that means people can no longer see they did it, which reduces their status. If the desire for status is stronger than the desire to have fun, it is driven by "ego".

 

10 years ago it was difficult to get PR's accepted into PLi and that is one of the major reasons why OpenViX and and OE-Alliance got created.
 
Even today stuff gets talked to death before getting acted on (if at all), and people just get bored and do their own thing in their own distro.

 

All part of the fact we're not a team, we're a group of "Einzelgängers".

 

There is no common design, there is no common architecture, there is no plan, there is no single goal to work to. Even a simple set of coding guidelines is missing, see the lenghty PEP8 discussion.

 

As a result, everyone does what they like (and skip what they don't), without it being part of a bigger plan. By themselfs, in their "attic room", and dumps it on the table when it's done, with a "take it or leave it" label attachted to it.

Because whatever is made will be a suprise to most people, and the first time they see it, that is when the discussion starts (you forgot this, did you think of this, what if this, etc...).

 

And because of the lack of a common direction, every one has their own idea's of how "they" would implement it. And for some it is difficult to accept their their approach might not be a good one (that is true for both the coder and the commenters).

 

That will only change if we decide to

• move aside our personal intrests and work towards a common goal
• actually define this common goal, in enough detail so people can work on it
• accept everyone has their own style and skill level, and might do things differently than you
• accept that you don't know everything, and take on bord feedback from others

I tried to push and pull (even called it flogging the dead horse) over the years, but as I'm not a Python or C developer, my efforts remained fairly high-level, and it subsequently failed.

[Huevos]

Yes , I guess some people aren't as patient as me, 

 

It is quite possible the file name is different to stop merges to those files. I don't know the history of that code but I was told it is different than the PLi version. I would need to look at a diff to know for sure.

[Huevos]

And because of the lack of a common direction, every one has their own idea's of how "they" would implement it. And for some it is difficult to accept their their approach might not be a good one (that is true for both the coder and the commenters).

 

And that is exactly what happened at OpenViX.  A contributor came up with a plan to add an embedded skin in the Python code of every module (so as not to maintain the skins he was breaking with his changes). I said no.

[WanWizard]

That can be avoided by adopting the "think before you code" methodology .

 

In my other OSS project, we're busy with the development of a v2 of the product, and we've spend months discussing on slack what the functional and technical requirements should be, documenting them in a wiki as we went along. Now that we have a blue print, developers can pick one of the jobs (usually at the class level) still open, and start work on them, knowning exactly what the class should do.

 

We always start with unit tests, which makes it easy to discuss the code at the functional level. Once the tests are ok, it doesn't really matter how the classes themselfs are coded, as long as the tests don't fail. Refactoring and optimizing can always be done later, as that wouldn't change any functionality of the code (the tests will enforce that).

[Taapat]

I personally do not understand why we need the same code in all images.

It would be the same to make everyone wear the same clothes and ride in the same cars because they would be easier and cheaper to repair and build.

 

The difference in images is what makes users choose between their, as they choose clothes, cars and everything else.

 

I see that many changes from OpenPli are merged in other repos.

But how many changes the OpenPli developers themselves offered in other repos that have nothing to do with OpenPli?

Also, changes from other repos in OpenPli very often come from the developers of these repos rather than from the developers of OpenPli.

 

So work together between all teams does not happen. And it's not because the code isn't the same, but because everyone has a primary interest in their own image code. If I don't use another image I don't test and don't offer changes to it.

Therefore, when you offer changes from another image you can slove conflicts if any exist in the code.

Of course, we could develop much faster if everyone works only on one project, but users want to choose between different images as they want to be different in everything.

Edited by Taapat, 17 April 2021 - 16:18.

[littlesat]

When they work together there are less forks... forks indicate that they do not work together... this is not about giving users choices.... this is more about doing more together where users can profit from...

[Huevos]

We don't need the same code in all images, we just don't need the unnecessary differences.

[littlesat]

Why do we need unnecessary images? It images unnecessary?

Edited by littlesat, 17 April 2021 - 18:44.

[Huevos]

Different distros so people can do different things. e.g. EPG in ViX is completely different to PLi, but epgcache is the same. So changes to epgcahe I would push back to PLi even though our EPG GUI is different.

 

What is crazy is making code changes that have no functional benefit.

Edited by Huevos, 17 April 2021 - 18:52.

[ccs]

Why do we need unnecessary images? It images unnecessary?

Are you suggesting OpenPLi is unnecessary ?

[Dimitrij]

 

I see that many changes from OpenPli are merged in other repos.

But how many changes the OpenPli developers themselves offered in other repos that have nothing to do with OpenPli?

Everything is correct.

I'm also busy only with openPli and can't waste time on other images. Because time is limited.

[Persian Prince]

Is there a place here that I can write about PRs only for devs/contributors not normal users?

 

I'm tired of seeing/reading nonsense and I beg you for that private place, somewhere that we can talk ONLY about cooperation and NOTHING more.

 

I only want to offer my help I hope you understand.

 

More PRs:

 

https://github.com/O...igma2/pull/2926

 

https://github.com/O...igma2/pull/2927

 

https://github.com/O...lugins/pull/657

 

https://github.com/O...lugins/pull/658