• 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 7
What are the reasons you don't submit your addon to official repo?
#46
I have to agree with the faster updates, a couple of days is way too long. Surely the process could be accelerated using some automated tools such as checking for the icon and screenshot and add-on structure, web submission ect.

If someone is updating an add-on that has already been verified then it should be instant really.

I think this is how Google play works. Apple are a lot more restrictive as we all know.
Reply
#47
(2013-03-16, 12:35)zag Wrote: I have to agree with the faster updates, a couple of days is way too long. Surely the process could be accelerated using some automated tools such as checking for the icon and screenshot and add-on structure, web submission ect.
atm for plugins the max is about two days (usually one day) and imo that not way too long.
sure perhaps new plugins take a little longer but then there should be no problem at all because not a single user is affected.
if the plugin is error prone you need to catch that in the code and throw a popup that fix is in the way.

what you guys also forget is that people sometimes sleep, don't use xbmc or don't even that plugin or whatever.
thake that time into the equation and then two days (or less) isn't that long
so take things into perspective.
Quote:If someone is updating an add-on that has already been verified then it should be instant really.
even if it was approved previously you can still have a problem.
imo we still need a pair of eyes too see the changes in whatever environment there is. if it's like current way or a webfrontend or whatever.
if it was a way where we could check it where ever we are (like at work or on a tablet) approval time could be way faster because we would need to be near our dev machine.
just hit a button but still there needs to be some one looking because we have way to many users.

it's not about trust but more about being cautious before pushing to a wide user audience.
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
#48
I'd tried to make it a bit more clear for newcomer devs to get started (similar to the skin dev section)
http://forum.xbmc.org/showthread.php?tid=160975

At the moment the wiki still needs a lot of work to get in decent shape. I will reorganize some more to give it more structure. After that it would be great if some of the more more experienced devs could help to get some simple example add-ons on it to show how things are working.

I also want to expand a current section that shows specific examples on how to use the XBMC python modules and the more common python code snippets. This currently still contains some deprecated code snippets so i will need to clean those up first.
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
#49
Regarding review, I presume what happens is you pull the add-on in as a single commit then do a diff and check for changes?

This process might be made better if we moved to github (as a pull req could be done) but ofc that means the add-on author needs to checkout the entire repo they're interested in (e.g. the entire plugins repo). I dunno if this is much effort for add-on devs (they wouldn't have to do it, it'd be an additional option). Moving to github has some downsides, but for the most part I think they can be eliminated.

Also, not sure if the add-ons repo that they check out could be developed in (i.e. I'm not sure it makes sense for the main repo to have all the development commits in it) or whether we'd want a squashed commit per version bump.

Thoughts from those that already use github for their add-ons?

Cheers,
Jonathan
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
#50
(2013-03-31, 00:05)jmarshall Wrote: Regarding review, I presume what happens is you pull the add-on in as a single commit then do a diff and check for changes?
That's what I do indeed (and others too i think)

Quote:This process might be made better if we moved to github (as a pull req could be done) but ofc that means the add-on author needs to checkout the entire repo they're interested in (e.g. the entire plugins repo). I dunno if this is much effort for add-on devs (they wouldn't have to do it, it'd be an additional option). Moving to github has some downsides, but for the most part I think they can be eliminated.

Also, not sure if the add-ons repo that they check out could be developed in (i.e. I'm not sure it makes sense for the main repo to have all the development commits in it) or whether we'd want a squashed commit per version bump.

Thoughts from those that already use github for their add-ons?

Cheers,
Jonathan

It would definitely make it easier for repo maintainers if add-on devs could make a PR to repo github. This way we can check the diff any time, anywhere and merge when it's ok. Now we have to be on our dev machine to get it in.
Development in repo git is a no go imo. During devcon we talked about this and we do not want all the commits in repo from every dev for every addon. So they need to still use their own repo for this.
We only want one single commit for each addon for each version. I am sure some addon devs know how to squash down commits into one or just do the same we do now and copy the code from their repo to our repo and make a single update commit.
Maybe there can be a more automated way of handling this and somehow semy auto the PR from their to our repo and squash it into one commit.
Ofcourse this should all be optional for devs still using non git repos like SVN or just plain zip pulls.

Any thoughts from devs on this?
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
#51
I don't think it's a huge task to ask devs to create a github account for their pulls (I think even google code supports git now).

The problem is there would have to be a picture filled step by step guide on the whole thing (creating a new repo, squashing commits, sending PRs and etc) for all three major platforms.

Getting started with Github is a huge, steep uphill journey. Once you're there and looking down, it's not so bad lol

How would you handle origination? This is the only thing that comes to mind and it seems clunky:
1. Team xbmc creates a project called plugin.video.foo
2. Developer forks that project on github
3. Developer does all his work
4. Developer squashes commits
5. Developer sends PR
6. Team xbmc reviews code
7. Team xbmc pulls in squashed changes
8. Loop from step 3
Reply
#52
I would suggest the following workflow:

Generally:
- Team XBMC creates an all-addons-Repo (lets name it ALL-REPO) on github
- add-on devs still (may) have multiple repos for multiple add-ons (github, gitbucket, svn, whatever vcs)
- add-on devs fork ALL-REPO once at github

On release or add-on update:
- add-on dev does development (in so much commits he wants) in his own repo (lets name it ADDON-REPO)
- <a script which needs to be written> will copy the ADDON-REPO's working copy into ALL-REPO/<addon> and does one commit there
- add-on dev pushes to his ALL-REPO fork and opens PR on github

regards,
sphere
My GitHub. My Add-ons:
Image
Reply
#53
@sphere
that was indeed the basic idea I (and some others) had to Smile
The point is we do not want to make it any harder for addon devs than it is so it should be semi automated as much as possible with step by step guide for new devs.
Git has indeed a steep learning vurve but once you know it it's not bad at all.
And most important optional. We don't want to force them using github.
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
#54
Yes, of course my workflow is a new method next to the actual one.
My GitHub. My Add-ons:
Image
Reply
#55
How much do all addons in the official repo and their git history's "weigh?"
After forking ALL-REPO, devs have to download everything, then the changes for all addons when fast forwarding. That may be bad for those with bandwidth caps or slow/flaky connections. Might be ok if it's not TOO heavy.
Reply
#56
(2013-04-01, 16:32)Bstrdsmkr Wrote: How much do all addons in the official repo and their git history's "weigh?"
After forking ALL-REPO, devs have to download everything, then the changes for all addons when fast forwarding. That may be bad for those with bandwidth caps or slow/flaky connections. Might be ok if it's not TOO heavy.

atm
plugins 182mb
scrapers 11mb
scripts 123mb
skins 1.23GB
webinterface 10.3mb

So definitely not one big repo and keep it split up like it is now.
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
#57
For me mail submit is the problem. We could have devel repo and full access for it then devs can take regularly from there to main repo.
Second issue is I am lazy and sometimes I am too late to fix things. I don't want to create problem on official repo. I don't want to take to much responsibility Smile
Reply
#58
For me "Register with the Add-ons Mailing List. This is the place to submit your work and also the place where other authors will contact you with pull requests for translations and patches." is where you lost me.

If someone wants to do a pull request, they can do so on github and I'll get notified. If someone finds a bug in the add-on they can leave a message here on the forum in the specific add-on topic thread or create an issue on github in which case I will also get notified.

I write add-ons primarily for myself (2 or 3 so far) and share them with the idea that they may be useful for others as well. I don't do it for fame and I don't do it so I can beg people to press the +/- button to increase my reputation (I guess I'm too old for the 'I like' generation; you like what I did? Cool. You don't like it, fine with me as well).
I don't intend to write many, so keeping up with the latest developments in add-on design is not important to me.

I don't want to be spammed by a mailing list that I don't need and read. Alternative would be to sign up to the mailing list, get the add-on in the official repo, sign-off of the mailing list.. but I don't have an honest feeling by doing that.

Just a couple of lines all starting with "I don't" which probably gives a good idea why I don't Smile (Why do I suddenly feel like I'm on the couch at the shrink? The mailing list isn't the real obstackle, I have other issues Wink)


Now, if there had been a simple webpage where I could upload my add-on I most likely would have done it. I see the following fields:
  • Email Address
    To allow the author be notified automatically as soon as his add-on is marked as broken and for contacting the author in case of remarks on his code.
  • URL
    This is where the add-on zip file can be downloaded from for review and storage into the official repo.

But may be I'm oversimplifying things..


P.S. "This is where all updates and important information will be announced." raised my eyebrows as well.. I'd expect the info to be announced here on the forum/wiki instead, not on some hidden away mailing list which the average Joe is not aware of.
Reply
#59
As already said before, I don't think github is a good idea for all devs.
People should be able to use what they want: svn, mercurial, or even just zip if they want.

I think a website is a good idea. People could give an url (git/svn/hg/zip) like they do today via e-mail.
With a basic API, we should even be able to provide a small script to make the pull request, so that more advanced users don't have to fill a web form.

In the background, a script could do basic checks and make a commit in a dev repo.
In case of obvious mistakes (invalid xbmc.python version, eol...) the pull request would be refused and the author can fix it without having to wait for team XBMC feedback.
If it passes the basic checks, it will wait for review by a team XBMC member.

This is basically what I do today with my script to process e-mails pull requests (https://github.com/beenje/addon-pr):
- get the add-on
- basic checks
- commit to my local repo if it passes the checks
Then:
- human review
- push to repo if everything ok or delete commit if not

So basically it's "just" to put that script behind a web server ;-)
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
#60
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.
For python coding questions first see http://mirrors.xbmc.org/docs/python-docs/
Reply
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 7

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