• 1(current)
  • 2
  • 3
  • 4
  • 5
  • 7
What are the reasons you don't submit your addon to official repo?
#1
We would like to know why some of you won't submit you addons to the XBMC official repo?
Some of you only supply a .zip link to install it from, others supply their own repo.

We are just curious why that is and what we can do or need to change to get more contributions to our addon system.
(some are obvious though like piracy content)

Is it the guidelines/rules, submission process, it's just easier for you like you have it now?


I hope you will let us know the reason Smile
thx

This discussion can be about plugins and scripts

Overview list of reasons:
*Not knowing you could submit
*Having to maintain separate versions for each XBMC release if code changed between versions
*Not allowed to contain binary files
*Submission process by email
*No Beta/Testing repo
*No Bug Tracking System
*No good rating / usage stats
*Devs find pushing to own repo is much faster / easier to update their addon instead of doing it to official repo.
*don't want a code review
*once a month submission too restrictive


Suggestion:
*split mailinglist in two: submission and announcements (or handle it different)
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
#2
I have about 24 add-ons in the official repository so maybe I'm not the real person to answer the question Wink

But I bet that you can increase the amount of add-ons in the official repository by adding advantages like a voting system and download statistics.
My GitHub. My Add-ons:
Image
Reply
#3
(2013-02-14, 19:29)sphere Wrote: I have about 24 add-ons in the official repository so maybe I'm not the real person to answer the question Wink

But I bet that you can increase the amount of add-ons in the official repository by adding advantages like a voting system and download statistics.

All advice is welcome. Addon stats will be after my holiday (will ask your help probably).
Ratings is something that needs to be well thought through but is also being discussed on how to work that out.

However what's the reason you have so many and others don't or have their own repo (although that could be useful for lets say beta testing)
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
#4
First reason, for me is a total loss of control on my stuff. Actually the official Frodo repo of XBMC is providing the version 1.7.6 of Advanced Launcher that do not works at all with Frodo. I have never submit this version for Frodo (only for Eden) but it is there. I have asked (more than 3 months ago) to remove this version of Advanced Launcher from the Frodo repo (or declare it as broken)... but nothing have been done yet. Really frustrating.

The second reason, is that actually a same version of Advanced Launcher is compatible with Dharma, Eden and Frodo versions of XBMC. So implies that the Advanced Launcher contains code parts that are only compatible with some versions of XBMC, even if these code parts are only executed on the version of XBMC they are compatible with (by using a simple python test). So it breaks one of the repo rules. It was told me that it was not possible to host the add-on in state and that it will be better to provide different version of Advanced Launcher (1 for each version of XBMC) with a different version number for each. You lost me at this time...
Reply
#5
(2013-02-14, 22:00)Angelscry Wrote: First reason, for me is a total loss of control on my stuff. Actually the official Frodo repo of XBMC is providing the version 1.7.6 of Advanced Launcher that do not works at all with Frodo. I have never submit this version for Frodo (only for Eden) but it is there. I have asked (more than 3 months ago) to remove this version of Advanced Launcher from the Frodo repo (or declare it as broken)... but nothing have been done yet. Really frustrating.

cheers for the feedback Angelscry!

when we opened the frodo addon repo, we did indeed move most of the addons from the eden repo to the frodo one.
this was done with the best intentions: to save all addon maintainers the trouble of having to submit their addon again for frodo.

we tried to filter out the incompatible ones as best as we could, but obviously we've missed some.
apologies if our efforts to save you all some work caused more trouble than it did good.

your addon has been marked as broken now. ;-)

(2013-02-14, 22:00)Angelscry Wrote: The second reason, is that actually a same version of Advanced Launcher is compatible with Dharma, Eden and Frodo versions of XBMC. So implies that the Advanced Launcher contains code parts that are only compatible with some versions of XBMC, even if these code parts are only executed on the version of XBMC they are compatible with (by using a simple python test). So it breaks one of the repo rules. It was told me that it was not possible to host the add-on in state and that it will be better to provide different version of Advanced Launcher (1 for each version of XBMC) with a different version number for each. You lost me at this time...

yup, i think that's the biggest hurdle for most of the addon creators.
the addon system we introduced in dharma had it's initial issues,
we've been addressing those over the last two years.

on top of that we've made a lot of changes to the python engine
and our json-rpc interface, both breaking backward compatibility for many addons.

i realize with each xbmc release we promise this was the last time we will break backwards compatibility
and starting with the next version of xbmc you won't have to go through the hassle of submitting a new
version of your addon, specific to this release, again.

i'm sorry we haven't been able to keep that promise...
but we're trying hard, really hard.

in retrospect, i think it just takes a bit of time with each new feature in xbmc
to get it into the right shape, stable and optimized.
Do not PM or e-mail Team-Kodi members directly asking for support.
Always read the Forum rules, Kodi online-manual, FAQ, Help and Search the forum before posting.
Reply
#6
To clarify it some more. For Eden and Frodo we almost had it were we wanted that it could share the same addon until we found out that versioning was a bit of a mess for both our internal addons, dependencies and 3rd party version.
That's the reason we decided that Frodo and Eden should be split up and that is just because of the addon.xml
Ofcourse if you used HTTP API you would still have to create a separate version.
For Frodo and it's follow up we have high hopes nothing will change for addons (except some additional functions). So for the majority of addons nothing will change unless they want to use some new functions.
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
#7
The two addons I maintain are both in the official repo, but the thing I find to be the largest hassle is the email based submission system. I understand perhaps having a manual process for the initial upload of an addon so you can do some quality control, but at some point it would be nice to get approval to just to some kind of pull request from my github repo directly to the addon repo.

I know of one case where an addon I use couldn't be in the main repo because it contained binary files. Again, I understand the concern, and I think I've seen something mentioned about a binary repo that might be coming. So that issue might be addressed later.
Reply
#8
We differ on interpretations of the "piracy" policy so some of my addons don't qualify. As for the remainder, the current setup doesn't make it very intuitive for the end user to tell the difference between the official repo and my private repo, so it's more fluid and user friendly to leave everything in my own repo.

The best solution I've come up to balance the differing points of view and user friendlyness is allowing private repos (but not necessarily the addons they contain) in the official repo. The pros:
1. Reduce the work load on team-xbmc (authors push their own updates)
2. Team-xbmc has a more direct approach available for indicating that addons are third party and not supported by the team (guaranteed to be shown with your preferred verbiage)
3. Adds a layer of separation between the foundation and any addons they disagree with, while removing a layer of ambiguity for the user. I liken this to the approach most linux distros have taken. They won't host certain packages for various reasons (copyright, ugly code, etc), but at the same time try to stay out of the way of users who are making a conscious choice to install and use those packages

The cons:
1. More users seeking support at xbmc.org, rather than fan sites. I count this as a con because there are some really strong fan sites out there with great communities, and I do think they would suffer from this. The increase in support requests would come from users who refused to read the information given, no matter how many alerts and popups we throw at them.
2. Still needs an implementation plan. For example, resolving conflicts from two different repos with the same script module version number but different code

Hope that provides some perspective and ideas
Reply
#9
+1 on add-on stats (and ratings I guess). This would be very encouraging!

I have two in the official repo, and one out. The one that is out has had by far the most work, is the most useful, and probably the most generally interesting - but it has binaries in it. And I fully understand why it can't get in - almost a relief as I don't have to worry about translations etc. so much, or the embarrassment of my code.

Re: versions - for me, I am basically of a mind to make a new version bump for each release, so for Frodo - the I leave the old branch behind and neglected. It's a hobby so I can't be bothered looking at old versions, etc. If they break on Dharma or Eden - well, a shame, but there you go....upgrade, people, upgrade Wink

Also +1 on doing it with pull requests - that would be way better. Emails/mailing lists suck for this sort of thing!

My biggest beef is the way it works with skins and addons - I really want there to be some sort of way to replace skin files from an addon that is allowed, but can be reversed if they uninstall. So in the end - install and uninstall processes that let one do more advanced things without sever hackery. This would make it much easier to do some cool stuff in addons. I could hack this in my own addon repo of course, and I am tempted, but then there is a lot less exposure. But say with my weather addon, the wiki provides a link to a MyWeather.xml for a few skins - to enable some advanced features. Would be great if these could come with the addon, but that would not fly with the master repo I am sure.

(This ties into my general issue with addons / skins - standard font sizes and ability to plugin into skins more easily would be awesome!!)
Addons I wrote &/or maintain:
OzWeather (Australian BOM weather) | Check Previous Episode | Playback Resumer | Unpause Jumpback | XSqueezeDisplay | (Legacy - XSqueeze & XZen)
Sorry, no help w/out a *full debug log*.
Reply
#10
my .02c...

primary reason for using email is that basing stuff on pull requests would mean git(hub) only - which isn't a sane requirement - lots of authors use e.g. googlecode.

second problem is that we cannot have hooks on github that react on push, so we'd need to external poll agent running, a more error prone, more involved and more taxing (on the backend) approach. sourceforge allows hooks, which is why the repos are over there still.

as for allowing third party repos in the official repo; this would tear down the borders between code offered by us and third parties we have absolutely no control over. that is not acceptable from our pov, since we feel/are reponsible for software offered on our servers. since the python in xbmc isn't sandboxed, there needs to be a HUMAN reviewing all the add-ons looking for harmful code. this is us behaving reponsible, not us distrusting other authors. sure, there can malicious behaviour (not gonna happen very often) or good old brainfarts on the authors behalf.
i think the fact that we do this is missed by a lot of peeps.
Reply
#11
(2013-02-14, 19:29)sphere Wrote: But I bet that you can increase the amount of add-ons in the official repository by adding advantages like a voting system and download statistics.

Yes! (its being worked on)


(2013-02-15, 04:43)pkscuot Wrote: The two addons I maintain are both in the official repo, but the thing I find to be the largest hassle is the email based submission system. I understand perhaps having a manual process for the initial upload of an addon so you can do some quality control, but at some point it would be nice to get approval to just to some kind of pull request from my github repo directly to the addon repo.

Yes!
Reply
#12
(2013-02-15, 16:56)zag Wrote:
(2013-02-15, 04:43)pkscuot Wrote: The two addons I maintain are both in the official repo, but the thing I find to be the largest hassle is the email based submission system. I understand perhaps having a manual process for the initial upload of an addon so you can do some quality control, but at some point it would be nice to get approval to just to some kind of pull request from my github repo directly to the addon repo.

Yes!

problem with this is that it will be a great barrier for new git users. Since we don't want history of all code commit you've done in our git repo this will require you to squash all commits into one version bump and then send a PR to us.
So how many regular addon developers would be able to do such a thing?

Ofcourse this would make it so much easier for us to do a review and hit merge button but this would only be something for the more experienced git users (if they use git at all).
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
#13
(2013-02-15, 15:40)spiff Wrote: my .02c...

primary reason for using email is that basing stuff on pull requests would mean git(hub) only - which isn't a sane requirement - lots of authors use e.g. googlecode.
another reason for using email is that we need to be able to contact the developer for feedback. another reason is that you get a email every time some one wants to update his addon. this could be very usefull in case you depend on that particular one.
Some time ago a dev wanted to update his script.module however that broke backwards compatibility. with the mailing list none of the others would have known that until it was to late. So all involved devs update their addon in one go to prevent breakage.

Quote:second problem is that we cannot have hooks on github that react on push, so we'd need to external poll agent running, a more error prone, more involved and more taxing (on the backend) approach. sourceforge allows hooks, which is why the repos are over there still.
Hasn't this changed since our forum is now handled by github to and once you push to master the server gets updated.
TheUni has more info on how that's done.

Quote:as for allowing third party repos in the official repo; this would tear down the borders between code offered by us and third parties we have absolutely no control over. that is not acceptable from our pov, since we feel/are reponsible for software offered on our servers. since the python in xbmc isn't sandboxed, there needs to be a HUMAN reviewing all the add-ons looking for harmful code. this is us behaving reponsible, not us distrusting other authors. sure, there can malicious behaviour (not gonna happen very often) or good old brainfarts on the authors behalf.
i think the fact that we do this is missed by a lot of peeps.

Indeed. We are semi responsible for the things put in repo that no harmful scripts get added. It doesn't even have to be on purpose. Just a badly placed while loop can be enough to cause mayhem (this is more for the python beginners)
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
#14
My proposition could be not appropriate and surely old school, but why not make a system based of 3 official repo (stable, testing, unstable) with a submission system based on FTP.

There will be first the "unstable" Repo where developers will have FTP access to a directory corresponding to their add-on (created by XBMC repo maintainers). Then developers will be free to propose/updates their stuff into the format they want (zipped or not). Do not need to have GIT/SVN functionalities. The repo will be only for providing stuff, not for development purpose. GIT/Sourceforge/GoogleCode services are already dedicated for that. The Repo will not be directly accessible for XBMC users and they will need to check an option into XBMC to access it (and be informed that it would be at their own risk and that the XBMC team was not responsible of the content).

When a developer thought that the version of his add-on is sufficiently stable it will put it on the "testing" Repo (again through FTP). Here XBMC repo maintainers will check if the add-on respect the rules to be accepted into the stable Repo. If not... developers will have to propose a new candidate version. If the add-on is accepted, the XBMC repo maintainers will put it into the official stable Repo. XBMC users do not need to have access to this repo from XBMC.

The stable repo will be similar to the on we have actually.
Reply
#15
You make good points about the code review. I still feel like there is something to be done to lower the "red tape" currently required.

Is anyone more familiar with how Ubuntu (for example) handles their submissions and review? (I only have a vaguely fuzzy idea) It seems from the outside that with so many contributors and packages, that whatever system they have in place would be pretty battle-tested.

Quote:as for allowing third party repos in the official repo; this would tear down the borders between code offered by us and third parties we have absolutely no control over. that is not acceptable from our pov, since we feel/are reponsible for software offered on our servers. since the python in xbmc isn't sandboxed, there needs to be a HUMAN reviewing all the add-ons looking for harmful code. this is us behaving reponsible, not us distrusting other authors. sure, there can malicious behaviour (not gonna happen very often) or good old brainfarts on the authors behalf.
i think the fact that we do this is missed by a lot of peeps.
The picture I have in my head serves to add to that border, first by giving you a chance to say "Hey wait a minute! These are untested and unofficial and will set your machine on fire" or etc. I don't think you can keep people from installing repos with bad software. I feel like the best approach there is to educate those willing to listen (nothing you can do about those who aren't). The second is by peer review so for example:

I push out a service addon that opens an elevated command prompt and runs deltree "C:\windows" in a loop forever. 5 users get hit and flock to the forums. Team-xbmc sees what's going on and black lists my repo, preventing it from spreading any further. Users who manually install this new service are still boned, but nothing you can do about that anyway. If team-xbmc becomes the connection point (even through the chain of providing the repo only) for discovering all addons, then you actually gain a measure of control. I realize that this isn't a perfect or completely feasible solution, but I hope that discussing it's merits and shortcomings can lead in that direction
Reply
  • 1(current)
  • 2
  • 3
  • 4
  • 5
  • 7

Logout Mark Read Team Forum Stats Members Help
What are the reasons you don't submit your addon to official repo?1