[sub3]

I'm not yet sure if these changes will improve the process or make it worse, but @h.udo please transfer pvr.nextpvr to sub3 account.

[h.udo]

I'm not yet sure if these changes will improve the process or make it worse, but @h.udo please transfer pvr.nextpvr to sub3 account.

Transfer process started and valid for 24h (github deadline).

[opdenkamp]

Why do you think that addons authors won't send PRs for this, they have been doing that ever since. Having our own repos as master just gives us more control and the possibility to fix things should we need/want to.
I'm 100% sure stuff will break regularly when we just point to external repos master branch. And users will come to us for help/complaints, not the addons authors.

agreed, we should keep the repos used for releases, and add-on authors' repos should be used as upstream, as we've always done.

[scarecrow420]

If we did that, could they main addon maintainer have write access? Previously there's alot of times that pull requests sit for days/weeks without getting merged. I guess at least we won't need a commit on Kodi side as well to pickup latest addons?

[h.udo]

If Kodi's side points to master, yes it should be automatic.
See https://github.com/xbmc/xbmc/pull/6227 and specifically https://github.com/Montellese/xbmc/commi...24c4fb4ca5

[emveepee]

What about translation, API and other global code changes? Who becomes responsible for ensuring all those PRs' get included in the pvr master before the pvr owner submits the PR for the txt file change? That part of the previous system worked very well.

Martin

[sub3]

My fear is the proposed new process will require me to make all those small API/stub changes, whenever there is a small change to the PVR API. Currently I don't need to do anything with those, and magic elves keep my addon up to date. So... my preference is something like we're doing today, via the Opdenkamp repository, but with write access so we can get out changes merged quicker, or some other way to speed up the pull requests.

I'm a busy guy, and a few times a year I'm out of the country for a couple weeks, and it would be annoying for my addon to be broken by API changes when I'm thousands of miles from my development machine, and not in a position to do anything about it.

[FernetMenta]

My fear is the proposed new process will require me to make all those small API/stub changes, whenever there is a small change to the PVR API.

maybe someone can jump in, maybe not. the point here is that it is not as simple anymore. some extension points (API) are going to be used by other addons as well. we can try but you should not rely on others completely take care that your addon won't break.

[FernetMenta]

after some discussion we decided to create an organization on github which hosts the addons
https://github.com/kodi-pvr

I vote for addon authors having push rights to their addon but that is not decided yet.

[negge]

I see I got invited to the organization, thanks. There are some people I'd like to give write access to for the pvr.hts repository, can I do that somehow or does an owner have to do it?

[scarecrow420]

after some discussion we decided to create an organization on github which hosts the addons
https://github.com/kodi-pvr

I vote for addon authors having push rights to their addon but that is not decided yet.

Yes, im not sure I get a vote but I would very much like to be able to have push rights over pvr.wmc


Just a question - the Kodi build system now has a text file that references what addons to pull in. But it seems this contains a commit hash and not just a branch. So that means Kodi wont automatically take in the master branch of each addon and we will need to do a PR to kodi to bump the commit (for each specific addon) when we want to get it into Kodi alpha builds?
Wouldnt it be better/easier to have Kodi pull latest commit from master branch of the PVR repos, at least while in alpha stage?


Also what is now the best way as an addon author to keep on top of things happening in XBMC that require us to update our addon with some kind of change (eg new API version)? How will we know if our addon is failing in Kodi builds all of a sudden?

[opdenkamp]

You can't develop directly in the kodi-pvr repository because force pushes have been disabled. Once a branch is created, you can only do normal pushes. So everything has to go through pull requests, and I prefer to have the kodi-pvr repository itself team only.

Discussed this with Fernetmenta. We need to adapt the build system to be able to pull a master branch from whatever you guys use to develop during the alpha period. Once we reach beta and branch off, we switch back to kodi-pvr to do the pre-release and release builds.

That will allow you to do whatever you feel is neccessary for nightly builds, and gives us full control over what ends up in our releases and repositories.

[scarecrow420]

By write access I meant ability to merge pull requests rather than working directly in the repo.

But anyway the process you outlined sounds workable

[Hedda]

So is it https://github.com/kodi-pvr that is the active upstream master now, soon, or never?

If not will they link to/from the active upstream master for where to submit pull requests?

[h.udo]

Yes, that's the active upstream master now.