• 1
  • 2
  • 3(current)
  • 4
  • 5
  • 7
What are the reasons you don't submit your addon to official repo?
#31
(2013-02-22, 13:55)takoi Wrote: Correct me if I'm wrong but wasn't the plan to allow same revision in both eden and frodo this time around? But then someone decided to change the version scheme and it all went to hell?

yup, that's entirely correct (also see: http://forum.xbmc.org/showthread.php?tid=156190)

all the addons in our repo had their stuff sorted, so there was nothing wrong with them.

it was the addons included in xbmc (xbmc.python, xbmc.json, etc..) that were still using the outdated x.y versioning scheme
instead of the x.y.z revisions all other addons are using.

we decided to fix this issue, knowing it would affect several addons depending on the xbmc built-in addons.

shit happens and it sucks i know.
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
#32
(2013-02-14, 19:35)Martijn Wrote:
(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.
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.
This would be really nice and I'm sure, more people would submit their addons.
Is it possible to publish the number of downloads of the latest version? Because the simplestats.xml (total downloads) is not really representative.

They seem to be already available (but not published) for the last 2 years:
(2011-05-05, 08:18)jmarshall Wrote: We have better numbers using analytics now. The plan is to use those for 2 metrics:
1. Total downloads.
2. Number of downloads of latest version (kicks in ~7 days after release of a new version).

(2013-02-19, 17:19)malte Wrote: Maybe we could have a versioning of these files like you already do with the databases. Allowing different versions of these static files being shipped with our addons (addon-12.xml, addon-13.xml, changelog-12.xml, ...)
Good idea! Because its really annoying to always have to push multiple versions. I planned to discontinue support for eden because of that...
Another solution: One addon.xml like before, but with multiple "requires" elements:
Code:
<requires>
  <import addon="xbmc.python" version="2.0"/>
</requires>
<requires version="12">
  <import addon="xbmc.python" version="2.1.0"/>
</requires>

Everything else is fine at it is for me... Smile
Reply
#33
I'm a rookie at writing plugins and I recently made them public and pushed them on github:
https://github.com/nightflyer73?tab=repositories

The first thing that is not very clear is if my plugins are acceptable for the official repo. The following sentences are a bit vague: "All files must be free and legal to distribute. The add-on must not violate any known copyright laws - if in doubt, let us know and we'll look into it for you. " . I imagine that some developers would not spend their time asking (and BTW where should they ask?).

I really think the way to push an update to the official repo is too cumbersome. It should be as easy as to making a git push. You should trust your plugin developers otherwise they will go away and they'll start their own repo.

If you want to check their code quality (a good think IMHO), it could be a good idea to have a peer review process before the developer can push his plugin to the official repository, like it is done in many Linux distributions for RPM and DEB packages.

If you do not want developers to submit too frequent updates you should create an unstable repo, where the developers can push their updates as often as they write code and early adopters can test them and provide feedback before pushing to the stable repo. For example without testers I couldn't find a blocker issue affecting two of my plugins on Android and ATV, platforms I don't own and I rarely have access to.

And last but not least, you should also have some kind of bug reporting feature (bugzilla, trac, whatever) for the addons in the official repo. It's not easy for a developer to track the bugs reported in the forums.

Just my 2c, HTH.
Reply
#34
(2013-03-02, 12:54)nightflyer Wrote: The first thing that is not very clear is if my plugins are acceptable for the official repo. The following sentences are a bit vague: "All files must be free and legal to distribute. The add-on must not violate any known copyright laws - if in doubt, let us know and we'll look into it for you. " . I imagine that some developers would not spend their time asking (and BTW where should they ask?).

i'll try to shed some light in the darkness then :-)

legal and free to distribute:
- first and foremost it means you release your work as open source, this should be done by including a license file in your addon
- second, you can't include the work of others if it's copyrighted. things like copyrighted fonts or artwork are examples of this

not violate copyright laws:
- the so called 'piracy addons'. add-ons that link directly to pirated content and enables the user to access that content through the add-on aren't allowed

when i doubt, just ask either on the addon mailing list or in our python development forum

(2013-03-02, 12:54)nightflyer Wrote: I really think the way to push an update to the official repo is too cumbersome. It should be as easy as to making a git push. You should trust your plugin developers otherwise they will go away and they'll start their own repo.

If you want to check their code quality (a good think IMHO), it could be a good idea to have a peer review process before the developer can push his plugin to the official repository, like it is done in many Linux distributions for RPM and DEB packages.
code review is something we value very much. a large part of xbmc development is also done this way.
i'd like to stress it has nothing to do with mistrusting anyone, it is nothing more than just an extra pair of eyes on the code
to try to filter out any silly errors (which we all make at times, we're only human after all).

as for making the submission process easier, spiff explained things a bit here:
http://forum.xbmc.org/showthread.php?tid...pid1336938

(2013-03-02, 12:54)nightflyer Wrote: If you do not want developers to submit too frequent updates you should create an unstable repo, where the developers can push their updates as often as they write code and early adopters can test them and provide feedback before pushing to the stable repo. For example without testers I couldn't find a blocker issue affecting two of my plugins on Android and ATV, platforms I don't own and I rarely have access to.
personally i never thought there was a need for it, but to my surprise quite a few have brought up this idea.
it's certainly something we should discus to see if we can make it happen.

(2013-03-02, 12:54)nightflyer Wrote: And last but not least, you should also have some kind of bug reporting feature (bugzilla, trac, whatever) for the addons in the official repo. It's not easy for a developer to track the bugs reported in the forums.

noted. will add this idea to the list on the first post.
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
#35
A lot of my add-ons contain very old code from the day I started Python. Some bits are difficult to read, even for me. Some contain hardcoded strings or write to the add-on directory. I have to clean them up first.

I will try to get an updated version of my NHL Videocenter in the official repo this evening. Every Channel is working now, including a search function.
Reply
#36
The list so far:


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)


Any others?
In the mean time we'll start thinking of some of the issues mentioned and how to possibly solve them.
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
#37
(2013-03-13, 23:12)Martijn Wrote: Overview list of reasons:
*Submission process by email

Suggestion:
*split mailinglist in two: submission and announcements (or handle it different)

Any others?

Why not using a web tool for submissions?
Reply
#38
That's not a reason for not doing it like we were discussing in this thread. We already thought of such option
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
#39
(2013-03-14, 10:10)nightflyer Wrote: Why not using a web tool for submissions?

If all that means is I have to fill out all the same information I used to send in an email in a web form instead, then that isn't a solution. It's just a different technology to do the exact same thing. For me, it isn't the email part that I dislike, it's the process.

That said, I think the XBMC devs have made some really good arguments for the current process, so I'm willing to stick with it and see what kind of tweaks can be made.
Reply
#40
My idea for a web submission tool would be 1 click upload with everything integrated from the forum such as emails and names. You would be able to quickly check the stage of process using another web page any time.

This is how Apple and Google do it with their app stores. It works quite well as a fair amount is automated, but there is no need to loose the personal email communication.

Hopefully that would make the process easier for the add-on creator and the moderators.
Reply
#41
Personally I am fairly happy with the current situation. I think it's great that addons in the main repo have been screened by actual people (and appreciate the work that entails).
I think the normal user doesn't care or understand that the addon was written by someone other than the XBMC team, and problems with and addon will therefore reflect badly on the users experience and on XBMC as well.

I currently keep my own repo for constant feature and bug updates, and and then decide it's a good time to update the main repo and feature freeze until I have a stable version and update the main repo.
So, I suppose I could do more updates to the main repo, but it all boils down to the fact that I'm to lazy to do that Smile

I will probably never keep multiple versions for the different versions of XBMC. So I'll update for Frodo, and Eden will no longer concern me.

I appreciate the dedication the XBMC team members and developers have to maintaining their part of the project. I have to admit that I couldn't do it. One of the things I like about writing addons is that I can do it in my leisure. It's a way of contributing without having to having to worry about deadlines and such that would interfere with my other responsibilities and activities. I've spent many hundreds of hours writing addon code, but I still think the ones who commit to supporting XBMC more officially deserve the kudos for their work.

I guess what my rambling has brought me to is that the current process makes sense to me, and makes sure that the addons that make it to the main repo required some commitment by the developer to adhere to a set of standards. While I don't believe it should be difficult for it's own sake, if it was too easy, I don't think we'd have the same quality that we have now.
I think it's great to be able to have my own repo, but when I submit to the main repo, I feel I have to step my game up a bit. I know someone is actually going to look at what I did and respond if I've done something wrong, so I can't help it. Without that, I honestly probably wouldn't try as hard.

In the end I think that, often as not, an addon isn't submitted to official repo because it shouldn't be. At least that's true in my case.
Reply
#42
Nicely said Smile
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
#43
I have made quite a few addons both in the official repo and in my own repo.
The reason for not submitting all my work to the official repo is both based on addon policies (and me not bothering to sort it out) and the dependencies I have between my addons...
Personally the process of the email list was quite confusing (a few years ago) but the wiki now explains it good. Still, I would like to see some leaner way of updating my addons and get better statistics and user feedback.
One idea for getting faster updates is when first time registering your addon you will have to pass through some code review but later you could get granted rights to update on your own will.
The API documentation and addon development is sometimes confusing and spread out in forum post, source code and wiki pages. Getting this in a better state would probably also help developers create "approvable" addons easier (not an easy task)...
#end of random thoughts..
Pneumatic | SABnzbd | XBMC that just works - openelec
Reply
#44
Quote:One idea for getting faster updates is when first time registering your addon you will have to pass through some code review but later you could get granted rights to update on your own will.
Update on your own is not something that is likely to happen. I don't see the real need for fast updating as most addons are handled within couple of days depending when you submit and repo maintainer is active.

The other parts are being worked on like improving wiki documentation which everyone can help with if they find something not clear or wrong.
Statistics is also something that will be improved in coming month(s).

Dependencies should stay the same between Frodo and Gotham unless you want to use a new feature that's only in Gotham.

Also what policies? More have mentioned this but most haven't actually mentioned which ones... Give examples which ones and what you think should change about that one (within reason)
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
#45
(2013-03-16, 00:15)Martijn Wrote:
Quote:One idea for getting faster updates is when first time registering your addon you will have to pass through some code review but later you could get granted rights to update on your own will.
Update on your own is not something that is likely to happen. I don't see the real need for fast updating as most addons are handled within couple of days depending when you submit and repo maintainer is active.
Well, a few days are sometimes a long time. Some plugins rely on parsing web pages and a single character could break them. If I'm fast as a developer my users a better off with my repo instead of waiting for a few days to get a update. I don't mean everyone should get update rights immediately, it should be something you earn by submitting good code...

(2013-03-16, 00:15)Martijn Wrote: Dependencies should stay the same between Frodo and Gotham unless you want to use a new feature that's only in Gotham.
I have dependencies between my addons. They are chained based on a API set and sometimes they need synchronous updates to work correctly...

(2013-03-16, 00:15)Martijn Wrote: Also what policies? More have mentioned this but most haven't actually mentioned which ones... Give examples which ones and what you think should change about that one (within reason)
I understand the reason for the policies (US laws) and we could leave the discussion with that.
Pneumatic | SABnzbd | XBMC that just works - openelec
Reply
  • 1
  • 2
  • 3(current)
  • 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