•   
  • 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  •   
What are the reasons you don't submit your addon to official repo?
#61
(2013-04-12, 00:19)Nuka1195 Wrote: Because you don't respond to my request Tongue

Not sure what happened, i'm getting the mailing list emails, but it said my request to join bounced and the PR bounced waiting for approval.

It's just a script that combines jfcarolls pypredef and the pydocs creator scripts.

Never saw the request mail.
Since i have no admin right on the mailing list i can't check what happened
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#62
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
Reply
#63
Any News about the integration of Github PRs and the official repository?
My GitHub. My Add-ons:
Image
Reply
#64
(2013-07-17, 19:32)sphere Wrote: Any News about the integration of Github PRs and the official repository?

Not yet. I was thinking about this last week. Since it's holiday season it will take some time to get the right people in place to discuss this.
I would definitely like it though
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#65
I only speak for myself (mainly because I am lazy, lol) I thought about submitting my add-on to the official repo but I decided not to for a few reasons:

I edit my code almost on a daily basis when a new feature pops into my head and I like to have complete control over my releases.
also because I made this add-on for my wife and decided to add some features to let other people have it, but it seemed to be less of a hassle to me just to set up my own repo.

like I said i'm lazy but there you have it Wink
Reply
#66
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.
No log no help.

Main page: https://github.com/Xycl
Repository: Xycl Repository
Reply
#67
(2013-09-17, 14:41)Xycl Wrote: 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.

If you don't want to discuss about the unix EOLs that's you choice. Same for any other "rules".


I really fail to see why it's so hard to do a one time change of the unix EOL for those 3 xml files.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#68
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.
No log no help.

Main page: https://github.com/Xycl
Repository: Xycl Repository
Reply
#69
(2013-09-17, 16:09)Xycl Wrote: 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.

Note that you don't need a script to do that. Git/svn/hg can handle that.
For git, see: https://help.github.com/articles/dealing...atform-all

So you could easily setup your repo so that when you accept a patch it automatically changes the files to unix eol.

You maybe gonna ask why we don't do that for the official repo?
Because I don't want to change what the user submit.
If we do that, why shouldn't we automatically resize the thumbnail as well?

The author is responsible for his addon and should be the one who makes the changes.
xbmc.log: /Users/<username>/Library/Logs/xbmc.log
Always read the XBMC online-manual, FAQ and search the forum before posting.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#70
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!
Reply
#71
(2013-10-03, 07:54)rob_webset Wrote: 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!

to not having this derail.

the "bugs" there are in the addons may as well be caused by XBMC audio system. you took over the addon from ronie and ronie expected you to update this in official repo as well. that you decide to suddenly not submit any more because you want to access core files which was disallowed since Eden release is about the same you not wanting to officially maintain this any more.
all skins except (give or take) depend on tv tunes so there are three options.
* you remove the reading of the guisettings.xml directly
* ronie takes it back for maintaining it (or some one else)
* every skin needs to remove the dependency on tvtunes or set it optional.

i'm not trying to be an ass here. these are the rules set in place by not me alone.
you could also do a version with the guisettings.xml reading code completely removed and add that to official repo and have one in your own repo with the code for the people who do want it.

these rules are set in place to protect the millions of users out there that could install the add-ons. we don't want them come back and complaining because some add-ons messes with their system. i won't name any other repo who lately had some issues regarding removing addons without any notice.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#72
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.
Reply
#73
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.
Reply
#74
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.
Reply
#75
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.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
  •   
  • 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  •   



Logout Mark Read Team Forum Stats Members Help
What are the reasons you don't submit your addon to official repo?1
This forum uses Lukasz Tkacz MyBB addons.