Login at Kodi Home

tjsuominen · 2013-02-12, 21:56

Hi!

And congrats on great Frodo aka XBMC release!!

I know that the dust has barely been released, but I am just curious that how the next XBMC release features / user-stories are to be selected and communicated or is there some community voting (besides the ones in Forum)?

//timo

jmarshall · 2013-02-12, 22:56

There's no voting on features either internally or externally (though I guess there's some "voting" on what gets included once the feature is already developed via review of the code, refinement of the UI, rejection of the idea at that point etc.)

Features get done as and when developers take the time to do them, it's really as simple as that. We don't promise things because it may turn out that we don't have the time to do them.

What I can promise is a 12.x build to fix a number of issues (small and large) that have been fixed already since 12.0. No new features, just fixes. Hopefully within a month, but note the word "hopefully" Wink

Cheers,
Jonathan

~~Robotica~~ · 2013-02-12, 23:55

There are a lot of unreviewed PR's on Github. With no roadmap (instead of a detailed roadmap aren't there plans and visions to share so devs have common goals and new devs can hookup?) or code review it's harder for new devs.

~~Ned Scott~~ · 2013-02-13, 00:34

I believe "inactive" PRs are periodically reviewed to see if they need to be closed or bumped/associated to/with a specific Team dev. It might not happen as much when things get busy, though.

**Memphiz** · 2013-02-13, 11:47

Main goal is to get this forum as empty as possible (because this would mean we are bugfree and have all the features in that all users over the wrold want to have). Wink

**Martijn** · 2013-02-13, 12:36

(2013-02-13, 11:47)Memphiz Wrote: Main goal is to get this forum as empty as possible (because this would mean we are bugfree and have all the features in that all users over the wrold want to have).

+1 on that Smile

~~Robotica~~ · 2013-02-13, 12:38

(2013-02-13, 00:34)Ned Scott Wrote: I believe "inactive" PRs are periodically reviewed to see if they need to be closed or bumped/associated to/with a specific Team dev. It might not happen as much when things get busy, though.

I am not sure about this: most pr's i am talking about don't have a milestone, someone assigned or a comment meaning the dev don't know how to progress.

~~Ned Scott~~ · 2013-02-13, 13:36

I'm not really that active on github, so this is just what I was able to gleam from some quick glances:

Of the ten oldest pull requests that are still open right now:

5 of them are from Team XBMC devs.
2 have comments from Team XBMC devs within a month.
1 seems to be included in one of the dev's test branches.
1 was commented on by an XBMC dev 11 months ago.
1 hasn't had an XBMC dev comment in 2 years, but deals with how to handle unmatched files from a scraper, which is a topic that is still under active discussion (we don't know which way it will be handled yet, etc)

That's just what we can see on github for activity. This doesn't record what other Team members do, like when we were getting close to feature freeze, a bunch of us were trolling through PRs to look for hidden gems.

Things can fall through the cracks, but most of the time if it's just sitting there for longer than 6-8 months and no one is assigned, then it's probably just a house cleaning issue and not simply forgotten.

tjsuominen · 2013-02-14, 10:38

HI all!

And thx for your comments on this topic. And no, I was not awaiting for answer "what" will be in for the next releases but just to understand how the process ("what") goes and seems there is no official one in place (= what will be developed / fixed) next.

What if, just a thought, there would be an option for community to vote getting something (candidates pre-selected by the dev team) in as next feature(s)? And yes, I know there might be disappointments but is that too "scary"?

Thx for good & open discussion!

//timo

**Montellese** · 2013-02-14, 10:42

I guess the reason we never did that until now was because every developer should be free to work on whatever he wants and even if it's a feature that nobody in the community cares about and there are tons of more wanted features. Furthermore a lot of things that are being worked on are not things that the end user will see i.e. code cleanup, improving the build system etc. End users won't have an immediate benefit from these things but it makes the life of developers much easier.

~~Robotica~~ · 2013-02-14, 12:04

(2013-02-14, 10:42)Montellese Wrote: I guess the reason we never did that until now was because every developer should be free to work on whatever he wants and even if it's a feature that nobody in the community cares about and there are tons of more wanted features.

Not a single policy that is going to stop the dev to do so but other devs may get some inspiration..

davilla · 2013-02-14, 12:14

eh ?

**natethomas** · 2013-02-14, 13:52

I guess it's hard to say from this end, but I somewhat assumed that most devs (both team members and not) who are heavily involved in the community tend to have a fairly good idea what is currently being worked on, by whom, and what most of the big community feature goals are.

For example, it's no secret that a great deal of work is being done on audio, Android hardware decoding, internal emulator support, upnp (and related server functions), Android functionality, smartplaylists, and ffmpeg. For the most part, essentially all development is done completely in the open, unless a dev is working on his own and wants to surprise everyone with awesomeness, which happens occasionally.

barberio · (This post was last modified: 2013-02-14, 15:30 by barberio.)

My "Not a vote" for next thing on the roadmap is to fix the outstanding issues with the buffering code. (Assumptions made based on local-media/low-bitrates that aren't true any more, and no rate limiting that leads to poor throughput.) There have been PRs outstanding on this for almost a year, the most recent one is https://github.com/xbmc/xbmc/pull/1388, and is currently included as a default patch on a lot of third party builds of XBMC.

It is certainly a bit demoralising that "submit a patch" is often used to berate people making suggestions, when there are significant PRs like this that go un-reviewed because lead-devs aren't interested in them. In particular I was told that I should "submit a patch" when I raised issues about buffering in the past, and started work on doing so, and then found that there already where patches submitted that have never been reviewed. This entirely stripped me of any desire to work on the project. Why waste my time, when it's a potshoot as to if a lead-dev will take enough interest to even consider merging your patch.

The lead-dev role in any project, be it open source or closed, is primarily about reviewing other people's code. A lead dev's own contributions shouldn't be what leads the project. Having to try and get the attention of a lead dev to consider something shouldn't be an issue, there should be someone on the project who actively goes through patches submitted.

A lack of a roadmap, or anyone in charge of reviewing patches, is a sign that the XBMC project has stagnated.

(2013-02-14, 13:52)natethomas Wrote: I guess it's hard to say from this end, but I somewhat assumed that most devs (both team members and not) who are heavily involved in the community tend to have a fairly good idea what is currently being worked on, by whom, and what most of the big community feature goals are.

That's absolutely impossible for anyone to do without an actual framework in any large project of any kind. If you just assume everyone knows what the plan is, there is no plan.

**Memphiz** · 2013-02-14, 15:22

eh ?