Posts: 53
Joined: Dec 2012
HELLO ALL
I am Deaf
Please help add-on edited
I would like to opinion help example
http://loads7.com/ to xbmc add-on
Thank You help for TUT
Martjin please privat nachtricht send me trank
Posts: 1,299
Joined: Jul 2009
Reputation:
59
sphere
Retired Team-Kodi Member
Posts: 1,299
Any News about the integration of Github PRs and the official repository?
Posts: 454
Joined: Feb 2012
Reputation:
13
Usually I get 1 to 2 patches per month from users. Normally nice to have user wishes.
After merging the patches and trying to send them to the official repo, very often I get back a mail concering the violation of the rule:
- all .xml/.txt must have unix style EOL's (because the merged patches contain non unix EOLs)
You (XBMC-Team) decided to write a text parser complaining about non unix style EOLs and I don't want to discuss the meaningfulness of this or other rules.
But I decided to not write a sed script to transform the EOLs.
Implied action is to immediately stop submitting to official repo.
Posts: 454
Joined: Feb 2012
Reputation:
13
It occurred more than once. Always after merging user patches.
Okay, you can tell me that I've Alzheimer's disease because otherwise I would remember these cases and could change these files before sending to official repo, but thread title is: "What are the reasons you don't submit your addon to official repo?"
And I told you my reason.
I really think that XBMC team has good reasons for these rules in terms of quality (like thumbnail size).
But exactly this is the reason why it's not wothwhile to discuss these rules.
You've to accept theses rules. Otherwise you cannot submit your addon to official repo.
With a suggestion of irony:
I really fail to see why it's so hard to do write a central sed script modifing cr (Mac) and cr/lf (Windows) to lf.
Posts: 979
Joined: Sep 2013
I have to say when I first started l looking at assisting with an add-on (DVDExtras and TvTunes) I did a little reading around and saw this thread and thought "I don't understand why people wouldn't submit plugins", however now I know! :-)
http://forum.xbmc.org/showthread.php?tid...pid1519549
In the end it's a choice of:
1) Having bugs in the official repo
2) NOT having bugs in your own repo
So a pretty simple choice - I think I'd prefer the non-bug option!
Posts: 1,088
Joined: Nov 2012
Reputation:
51
I dont think it is necessarily a derail, the responsibility of a core addon maintener aside.
It looks like another vote for: Prohibition against accessing databases and settings directly.
For me it was an impediment as my addon was partly for a few of my friends using Raspberry Pis, and accessing things through the JSON RPC makes things slower. But the benefit of easier access for my friends from the addon being in the official repo was enough to overcome it.
PS. My first solution was to copy the database in question to the addon data folder and then read that. Seemed a little cheeky though.
Posts: 2,571
Joined: Aug 2012
Reputation:
217
IMHO. A couple of reasons for submitting your addon to the official repo.
I never programmed for XBMC, wrote in python or used github until a few months ago. I am not new to design, programming or managing large groups of programmers.
I got up to speed by studying code from just about every dev that has posted to this thread, both in and out of the official repo. The documentation is getting better, but I've learned far more from reading the code.
I haven't read any code that should fear a code review, in fact I've shared a number of examples with my staff and my kids in university to help them understand some concepts. Some of the most creative pieces come from folks that stay out of the official repo which is a shame because it often takes a ton of time to initially track down an addon that's outside of it. People, even experienced ones, can learn a lot from the XBMC development community, I'm not sure that some of the more skilled devs realize this.
I assume most folks develop the same as I do, a local directory for development using install from a local zip until I'm happy, then I push the local directory to github, which I send an email to xbmc to pull from. From the time I'm happy with my local zip to pushing source to github and sending a pull to xbmc takes about 10-15 mins (i'm a bit retarded). It took a little time to understand and setup github but it wasn't inordinate. If I was in a hurry to distribute a change, I'd email the local zip or a link to my git.
I really appreciate the feedback I get when I submit to xbmc. Someone actually takes the time to review what I've submitted. The process has made me aware of up coming XBMC improvements/changes and allowed me to prepare in advance for those changes. I probably wouldn't have had that benefit if I stayed outside of the repo. The rules aren't onerous or particularly time consuming for anyone writing a new addon, though I could see some possible issues for legacy. Even in the legacy case, unless I was dropping support of the addon, I would be inclined to make the necessary changes to avoid lots of support issues going forward.
The improved submission/beta testing/bug tracking/rating/usage stat features are all good, but the lack of them doesn't seem a reasonable excuse not to use the official repo.
Posts: 616
Joined: Mar 2011
Reputation:
80
sarbes
Team-Kodi Member
Posts: 616
The main reason why I don't submit my addons is the quality of my code. Most of my addons contain snippets from my first steps in python. Even two years later the code quality of my late night sessions ist far from good. Coupled with badly programmed websites this produces a nasty (but mostly working) mess.
However, I have 4 addons almost ready to be submitted. They need a bit of cleanup first though (hardcoded strings, small bits of messy code). They also lack of proper descriptions, thumnails and a fanart.
Posts: 26,215
Joined: Oct 2003
Reputation:
187
Great! Look forward to it membrane. I'm sure if you want a hand with the artwork that others will be willing to help you out if you can offer directions.