[misa]

You know who you are, and maybe you should be the ones leaving. (there I said it)

Easy answer

[natethomas]

After reading fritsch's latest post http://forum.kodi.tv/showthread.php?tid=...pid2203872 its clear that its nothing to do with one specific PR or person, but a whole philosophy or project direction. I dont blame people for trying to whitewash over these things, but it detracts from the problem by doing so imo.

It is 100% absolutely about a single PR. The link you provided goes in depth about what fritsch feels is wrong with that PR, from the fact that he thinks it only helps one device (I've no idea if that's correct), to the fact that it's hacky and could break, to the fact that he perceives accepting the hack as a form of losing our cross-platform soul.

I'm genuinely not sure what he's talking about with

It was proposed, that platforms (Windows, Android, whatever) should get special branches and features should be allowed to be commited without honoring the cross-platform aspect, Those branches are then released as final versions.

My guess is that at some point the biggest complaint came down to the PR possibly affecting other platforms, and one proposed solution was just to build the Android branch separate, so it didn't affect the other platforms. This was suggested along with two or three other ideas for dealing with the problem, including if-defing and whatever else. If that's the actual reason he ultimately decided to pack his bags, then that's incredibly unfortunate, as it was just random spitballing as people tried to come up with a solution.

The most frustrating part, for me, of this past week has been this quote from fritsch.

I am not against features (as you see in this thread), but features that will degrade, break our code platform over time is a feature not worth it.

It's frustrating, because I feel like everyone is talking over everyone else's head. Literally every member of the team agrees with his statement, as far as I know. It's why we don't add features like Airplay anymore and generally try to avoid allowing reverse-engineered code into core that will result in constant platform breakage. The team universally agrees that allowing features in that will degrade our codebase is not worth it. This is simply not a point of contention.

The point of contention comes down to a simple question: Is the release version of Kodi 16 part of our codebase? It sounds like fritsch would say it is, which is fair, since it is code we are releasing. Koying, on the other hand, argues that it is not, because the official release of Kodi 16 is a branched, non-mainline version of our codebase that includes short term bug fixes, and as such, it cannot "degrade, break our code platform over time" because something only added into 16 without touching the mainline version of the code, by definition, won't be part of our code platform over time.

Quite honestly, this is an argument that needs a week's break, followed by some beers, a mediator, and a locked room, because I'm fairly certain everyone agrees about the generalities and, broadly speaking, wants Kodi to remain as it always has. The argument is about particulars: the definition of "bug fix," the definition of "code base," etc. It is times like these where I regret the fact that we have only one devcon a year, and I regret even more that many of the guys involved in this argument weren't able to be there, because that's EXACTLY where we could have resolved all of these particulars.

[Sandhills Hillbilly]

Sounds like to me some people feel like they are beating their heads against the wall.

One of my favorite quotes of all times "All you have to do is XXXXX"! Yeah Right

[da-anda]

while I agree with fritsch's vision I don't really understand his reasons to leave. Just like Koying I don't see how this PR, when handled correctly(!), would conflict with this vision. IMO it's a short term fix that only applies to v16 release and never hits master. Especially when, as it has been suggested, handled via an Android specific branch I don't see an issue. We had Android specific builds before. It's ofc not ideal, but I really don't see a big issue. I also trust Koying in this regard, because if he fucks up, as only Android dev he has to fix it himself anyways. Again not an ideal situation, but still no issue for me, as my focus is more on the user experience.

If we in general don't accept short term bugfixes anymore and expect every PR to rewrite large parts as it would be the more perfect fix, then I think we'll loose a lot more contributors (which we already did for these reasons). Don't get me wrong - long term goal should ofc be a clean architecture with stuff properly rewritten, but IMO short term fixes, especially for just a release branch, should still be allowed. Also "not that perfect" PRs by random contributors that don't conflict with parts that are currently rewritten. Many contributors of Kodi are no professional coders but still spend days trying to fix a particular issue, but instead of being thankful for the contribution, major rewrites are being requested that in many times are way beyond the contributors skills and thus the PR is abandoned/closed demotivated (been there myself). IMO even a not perfect fix is better then no fix at all or waiting another 2 years until the rewrite with proper fix has been done. But well, that's maybe just me.

edit: rephrased first paragraph a bit

[Razze]

Since this answer is 100% related to my point of view I'll answer one more time

This :

and didn't want to have wasted a week working on a bug fix because of a disagreement about definitions.

Is the major problem and will always be until some understand the implications.

Have X people coding things for themselves and hoping to have a merge, but could have loose lot's of time because one people do not agree can not work on such a large project. (I do not even talk about how some members talks to newbies this is out of context I just talk about pure code contribution by people that can make abstraction)

This will always lead to EGO problems, or lassitude problems or many other possible problems, no one can exit unharmed from such repeated things.

This one case was the one more case, not just the case that triggers the problem. (And IMO we all know Koying way of speaking and I'm sure most know how to make abstraction and take all the good things hidden )

But this is also a problem for external coders, no way to have a yes feature could be cool before, it's code, learn, then have anyone refuse the PR.

https://github.com/xbmc/xbmc/pull/8704 is a good example, even between the Team for a PR that will sure be refused, one say refuse before working more, the other say let's continue it will cause problems for external coders to be motivated.

The problem should have been handled way earlier when the user asked about it : http://forum.kodi.tv/showthread.php?tid=252889 and some other post where he asked how to start this

No one did answer anything ... So you can't use forum to discuss about things you want to add, then you loose 1 day / week / month learning then fix then make a PR, then sorry no way this comes in.

This is just completely insane IMO and a long term major problem.

I attempted many things over the years to try to make the Team understand the problem but there's no way to have answers, since there's no real lead for such things.

When I now see you ask for more devs, but continue to not handle external devs, I'm sad because it can't work on the long term.

I could have done a lot for JSON and Windows but until there's a way to discuss before coding, I prefer pass time with my wife than coding for nothing and I suppose it's the case for most sane people.

A small reminder of one of my attempts : http://forum.kodi.tv/showthread.php?tid=166398

We're very aware of that problem.
I actually did a talk on devcon about it - from the perspective of being a new team member back then, the problems of being outside of the team, how we could solve that etc.
Ment to do a forum post about that (I should really take time for that) or see if that video of the talk is okay to show to the public.

And one of the basic problems is that we're all just human and communicating over the internet is hard. Most times people seem harsher then they mean to be. Some are just checking github for some seconds a day and figure the other part will understand if their answer is just code related without being "nice". For others, it's just their nature of writing things online.
Others take more time, but nobody mean harm or to discourage anybody.

Some things we learned that help:
- Use smilies.
- Assume no malice.

As un1versal I did try to contribute a lot before, but have given up way earlier due to all those (Well in fact since I was 3 years before, it seems we have the same duration )

I now only do minimal support on JSON thread and check JSON PR to try to avoid catastrophe when I can, or answer to Montellese ping.

But no more by passion like before, just because I do represent 2 million users and feel responsible for them to ensure their needs can continue to be filled. And it's hard to see how things are managed, or when someone that have no idea of what he is talking about comes and say : no do not bump JSON API version just because he find it's cool to say so.

I follow XBMC since Xbox, I do follow code since 2009 and Camelot and have followed users reactions to XBMC move through my tools.

I had reported some stats earlier, but no one seems to have interest, but I'll bring a stat once again to the field.

On 1 million monthly active users that have anonymous stats activated : 65% (Yes sixty five percent) as still using 14.x or earlier. New version adoption rate is slowing down a lot with each versions and it should be an number to try to watch and analyse, because there's reasons behind those.

I'm not sure if I understand your frustration, out of 16 PRs from you 12 got merged. Not that bad it it? Sometimes feels like people want to be angry (I also do that, I believe)
https://github.com/xbmc/xbmc/pulls?utf8=...r%3Atolriq+

Also I remember our numbers are suggesting a good adaption of the newer versions, but that might be my brain messing with me, not sure would have to look it up.

[braz]

On 1 million monthly active users that have anonymous stats activated : 65% (Yes sixty five percent) as still using 14.x or earlier. New version adoption rate is slowing down a lot with each versions and it should be an number to try to watch and analyse, because there's reasons behind those.

My guess is these are the folks using the fully-loaded boxes (e.g., pirate addons) and they don't want to break their "build" by installing the new version.

[Tolriq]

I'm not sure if I understand your frustration, out of 16 PRs from you 12 got merged. Not that bad it it? Sometimes feels like people want to be angry (I also do that, I believe)
https://github.com/xbmc/xbmc/pulls?utf8=...r%3Atolriq+

You may want to read the PR discussions and all forum post I made about the problem before saying that it's just me wanting to be angry

Accepted PR where from another time when just Montellese in charge of JSON was answering and giving proper advice to have PR fixed. (Or jmarshall we miss you)

Then came the time of random people jumping in just to say no without any real reasons like elupus on https://github.com/xbmc/xbmc/pull/2773 then PR closed without any discussion (outside of the main problem).

The feature is still on the TODO list http://forum.kodi.tv/showthread.php?tid=163215, this is insane, the feature is not wanted leading to an half implemented JSON API, no problem but remove the feature from the ... TODO list to avoid any one else loosing time again. (Even if IMO since all the other commands do support recursive flags and code was infinite loop proof there's no reason to not include the feature but it's another story)

Another already given example that is in the complete history of what da-anda says : https://github.com/xbmc/xbmc/pull/2772

There's something missing, I do propose a way to handle it correctly as used in the whole HTTP world. The better solution is something that is for this particular need not better at all and will never surface in Kodi as way too big.

Both case are simple cases, that took more time to discuss than to code. But for larger problems like playlist handling that would lead to tons of work, do you really think I would take a chance to make all the investment for nothing and no way to discuss ?
Certainly not, and it's the case for lot of other peoples.

I could also talk about needed things that some do not want for strange reasons, like support of keymaps from JSON, just because those people do not have the need for remote means all users do not need those things.

Funny thing is that when the same people ask for this feature that they refused : https://github.com/xbmc/Kore/issues/46 forcing even internal Team member to use EventServer to fill user needs instead of addressing the root cause.

One more for example, is a user that ask why we can no more send key-presses from JSON after the drop of the HTTP api and the wonderful answer of a Team member that says : Stop complaining, you should have asked this before, but funny thing is that is was asked dozens of times and the same Team people refused to have this integrated.

And I have hundreds of example since all those years but this is out of the scope of this post, I just answer on what I felt as an insult.

Edit : About numbers I made a calculation mistake :p 100 - 45 is 55 not 65 But still a quite high number.

[thetazzbot]

Well, this has been educational.

I read the pull requests linked above and I must say that IMHO the Kodi team was right for rejecting a request from someone who admits that he is "new" to it and during a time when the project is in beta. You just simply DO NOT pull code that is not classified as "break fix" at beta time. The user was trying to squeeze in a feature during a beta release..

To even expect the team to pull in code like that during a beta is 1) vain, and 2) irresponsible to the project overall. Then to go on a rant that they didn't pull in the PR....

I want a stable Kodi. Not one that just lets any ole code in the door at the last minute. Thank you for that!

But then, I'm not one to really contribute to projects like this because frankly I don't have the energy to fight the political battles that you fellas are putting on display for us here. And I am glad you are sharing this in the open.

As so many times I have heard the "pull requests are always welcome!" mantra, whatever code is being submitted needs to be 100% tested by the developer on as many devices and use cases as possible. Not just one raspberry pi or vero and call it good. Developers need to do their fair share of testing, not just depend on the rest of the world to find their bugs.

Cheers,
thetazzbot

[Tolriq]

Well, this has been educational.

I read the pull requests linked above and I must say that IMHO the Kodi team was right for rejecting a request from someone who admits that he is "new" to it and during a time when the project is in beta. You just simply DO NOT pull code that is not classified as "break fix" at beta time. The user was trying to squeeze in a feature during a beta release..

To even expect the team to pull in code like that during a beta is 1) vain, and 2) irresponsible to the project overall. Then to go on a rant that they didn't pull in the PR....

I want a stable Kodi. Not one that just lets any ole code in the door at the last minute. Thank you for that!

But then, I'm not one to really contribute to projects like this because frankly I don't have the energy to fight the political battles that you fellas are putting on display for us here. And I am glad you are sharing this in the open.

As so many times I have heard the "pull requests are always welcome!" mantra, whatever code is being submitted needs to be 100% tested by the developer on as many devices and use cases as possible. Not just one raspberry pi or vero and call it good. Developers need to do their fair share of testing, not just depend on the rest of the world to find their bugs.

Cheers,
thetazzbot

Here's comes the guy that have missed a few things

The PR talked about is https://github.com/xbmc/xbmc/pull/8629 by one of the Team member, if you refer to my PR all are from before 2013 so well your comment is out of context

No one between Koying and Fritsch are new to anything

[Koying]

My guess is these are the folks using the fully-loaded boxes (e.g., pirate addons) and they don't want to break their "build" by installing the new version.

+1
Just check for people complaining that having Kodi on Google Play auto-updated their Android Kodi box.

As so many times I have heard the "pull requests are always welcome!" mantra,

You're mixing stuff. The "pull requests welcome" mantra is for people doing feature requests, then complaining it's not implemented (or not fast enough to their liking). Not for bugs.

[Razze]

As so many times I have heard the "pull requests are always welcome!" mantra, whatever code is being submitted needs to be 100% tested by the developer on as many devices and use cases as possible. Not just one raspberry pi or vero and call it good. Developers need to do their fair share of testing, not just depend on the rest of the world to find their bugs.

Well that's not correct. Test as good as you can without wasting to much time, but tell us in the PR what you did test, we will try to test the rest/if you missed something and see if the build fails on any platform, due to the changes. If it does, we will try to guide you as good as we can.
Depending on the impact of the change, we will do builds based on the PR to get people to test it.

If it get's merged and there are bugs that show up, we have enough time to find the problem/revert it due to our release phases.

[Big Aero]

On 1 million monthly active users that have anonymous stats activated : 65% (Yes sixty five percent) as still using 14.x or earlier. New version adoption rate is slowing down a lot with each versions and it should be an number to try to watch and analyse, because there's reasons behind those.

My guess is these are the folks using the fully-loaded boxes (e.g., pirate addons) and they don't want to break their "build" by installing the new version.

Or perphaps certain things do not function correctly/optimally ever since Kodi 15.....

On Intel hardware running Openelec 6/7 for example, when 576 50i live tv is playing with any HQ scalers enabled, the system GUI drops to 25fps, which produces 1000s of frame skips/drops the monent you load any GUI elements of Kodi - the outcome is a sluggish experience even on higher end hardware (not cool at all). Did it do this on Openelec 5 - 14.2? Nope, solid 50 fps and buttery smooth with absolute minimal frame skips.

Or perhaps because the tv guide actually takes longer to load after pressing the epg button on 15/16 than it did on 14.

Heck, channel changes are even quicker on Kodi 14.2 when you have cacheindvdplayer set to false. On Openelec 6 - Kodi 15 if you set cacheindvdplayer to false it can cause 100% cpu usage (on one core?) on certain channels.

Those are my reasons for staying on Kodi 14.2, and I'm sure theres many more reasons why others have not upgraded other than piracy related stuff.

You know that saying..... If it's not broke - don't fix it.

Anything above 14.2 on the Openelec platform is a downgrade IMO.

Kodi 14.2 FTW!!

[Tolriq]

My guess is these are the folks using the fully-loaded boxes (e.g., pirate addons) and they don't want to break their "build" by installing the new version.

+1
Just check for people complaining that having Kodi on Google Play auto-updated their Android Kodi box.

Assumptions versus real life data as often here

For example data from Sunday 3rd January 2016.

10% usage : xbmchelix / 14.2-stable / 14.2 Git:7cc53a9 / Rpi / 14 / OpenELEC (official) - Version: 5.0.8 (kernel: Linux 3.18.10) (2nd most used combination)
4% usage : xbmchelix / 14.1-stable / 14.1 Git:2015-02-02-81c4046-dirty / Rpi / 14 / Raspbian GNU/Linux 7 (wheezy) (kernel: Linux 3.12.31)

First android box is : xbmcisengard / 15.2-stable / 15.2 Git:2015-10-27-17fa8da / Android / 15 / Android 4.4.2 API level 19 (kernel: Linux 3.10.33) at 1.5%

First android box not 15.x is : xbmchelix / 14.2-stable / 14.2 Git:2015-03-26-7cc53a9-dirty / Android / 14 / Android 4.4.2 API level 19 (kernel: Linux 3.10.33) with 0.2% and it's 41th position ...

As I have already tried to explained, real data is the key to understand things, assumption and educated guess have limits

Users are not all the dumb that some wants to believe

And first release at 11% is now effectively a Isenguard : xbmcisengard / 15.2-stable / 15.2 Git:02e7013 / Rpi / 15 / OpenELEC (official) - Version: 6.0.0 (kernel: Linux 4.1.12)

But this is very very recent.

Edit : Well seems maybe asking the users directly does also works if you take time to consider them

[natethomas]

It'll be interesting to see how many of Aero's problems will be fixed with video player in Kodi 17. My guess is, based purely on the way the devs talk about it, it was mostly a matter of chance with dvdplayer whether things worked well or poorly from version to version, and most of that chance should be gone with the new Videoplayer.

[natethomas]

Tolriq, I have no idea how to read those stats you provided, so I don't know what they tell us.