How to handle STV updates

[skiingwiz]

I have a pull request almost ready that adds 2 new methods to the Favorites API (just waiting to be able to sign the CLA). I also have corresponding changes to the STV to use those new calls. That got me wondering... how are we handling STV updates in the open source version? Are we just submitting pull requests with updates to the SageTV7.xml STV file? (as opposed to the update mechanism built into the default STV? which I'm not even sure is being used for the open source version.)

Also, (mostly for Jeff) should there be one pull request with the API updates and another for the STV updates, or should they be packaged together in one pull request.

Since no one has submitted STV updates yet, I thought I'd start by asking.

[Narflex]

Originally Posted by skiingwiz

I have a pull request almost ready that adds 2 new methods to the Favorites API (just waiting to be able to sign the CLA). I also have corresponding changes to the STV to use those new calls. That got me wondering... how are we handling STV updates in the open source version? Are we just submitting pull requests with updates to the SageTV7.xml STV file? (as opposed to the update mechanism built into the default STV? which I'm not even sure is being used for the open source version.)

Also, (mostly for Jeff) should there be one pull request with the API updates and another for the STV updates, or should they be packaged together in one pull request.

Since no one has submitted STV updates yet, I thought I'd start by asking.

Ideally I would like them to be 2 separate pull requests since I have to approve pull requests as a whole. I'm still curious what happens if someone just tries to commit directly to the project and push the change that way....that's what I do (but of course I have rights to do that). Then we can just work with commits (which is what I'm used to normally doing in my workflow).

As for STV changes...those of course can be accepted; but be sure they're not better off as a plugin.

[stuckless]

Originally Posted by Narflex

Ideally I would like them to be 2 separate pull requests since I have to approve pull requests as a whole. I'm still curious what happens if someone just tries to commit directly to the project and push the change that way....that's what I do (but of course I have rights to do that). Then we can just work with commits (which is what I'm used to normally doing in my workflow).

As for STV changes...those of course can be accepted; but be sure they're not better off as a plugin.

If a person doesn't have access to push to YOUR repo, then they'll get a permission denied. I can clone directly from google/sagetv, but I can't push to it... ie, it doesn't create a pull request, or stage it somewhere... it just fails. (I haven't tried this with your repo specifically).

Typically for "features" you can put them in separate branches, and then push them as a single feature with multiple commits. (ie, related commits should go together)

I'm not sure you want to open up your repo to allow public commits... But something you can do, if you want to allow such a thing, is create ANOTHER repo that is public, and then you can cherry pick which commits you want from that repo, instead of people submitting pull requests. You'll be doing a lot more manual merging that way though.

[skiingwiz]

Originally Posted by Narflex

As for STV changes...those of course can be accepted; but be sure they're not better off as a plugin.

I've gone back and forth about that. This is the Enable/Disable Favorites plugin. Because the way that enable/disable worked was a hack (messing with the category of the favorite), I've added proper support and API calls to SageTV Core. So once the functionality is in the core, should the STV be updated to take advantage of it? Should a plugin be required to expose that functionality that exists in the core?

[Narflex]

Originally Posted by skiingwiz

I've gone back and forth about that. This is the Enable/Disable Favorites plugin. Because the way that enable/disable worked was a hack (messing with the category of the favorite), I've added proper support and API calls to SageTV Core. So once the functionality is in the core, should the STV be updated to take advantage of it? Should a plugin be required to expose that functionality that exists in the core?

This one I'd agree is a change that's fine for the core. And yeah, making a change to the STV to enable this feature would be fine. Let me check with Andy first to make sure we have the latest one in GitHub...

[Opus4]

Before any changes are made to the STV in GitHub, I would like to take a look at the STV I've been using that has a few more features from the past few years that might be useful and get a new one submitted.

I also agree that any new core features can be added to the STV w/o having to make a plugin for it.

I'll also be unhiding the hidden features.

Edit: and if I have access to an updated STV for new features, I can see about including those changes while I'm at it.

Andy

[skiingwiz]

Originally Posted by Opus4

Before any changes are made to the STV in GitHub, I would like to take a look at the STV I've been using that has a few more features from the past few years that might be useful and get a new one submitted.

Edit: and if I have access to an updated STV for new features, I can see about including those changes while I'm at it.

I was planning on updating the STV after my core changes are accepted. I have an STV Import I can send you when that happens that adds the new feature. (Or you can get the STV change from the pull request that I'd eventually create.)

[Opus4]

I finally had time to get the latest STV files in GitHub.

And, the hidden features are now no longer hidden. Instead, those features default to off, and there are options at the bottom of Detailed Setup -> Customize to enable/disable the features all at once or individually. I couldn't bring myself to completely get rid of 5309 on System Info... but it is no longer used to toggle the hidden extras setting. (Well, you can still kind of do it that way...)

Andy

[stuckless]

Originally Posted by Opus4

I finally had time to get the latest STV files in GitHub.

And, the hidden features are now no longer hidden. Instead, those features default to off, and there are options at the bottom of Detailed Setup -> Customize to enable/disable the features all at once or individually. I couldn't bring myself to completely get rid of 5309 on System Info... but it is no longer used to toggle the hidden extras setting. (Well, you can still kind of do it that way...)

Andy

Any chance you'll give a list of what those features are

[Fuzzy]

Originally Posted by stuckless

Any chance you'll give a list of what those features are

Pretty sure all they are the disk space bar, malore menus, numeric quick search, and marking of HD and 1st run on the EPG.

[Opus4]

Originally Posted by stuckless

Any chance you'll give a list of what those features are

They are all listed here: hidden features.

In addition to what Fuzzy listed, it also has default settings for new Favorite and Manual recordings, access to partial recordings, and a few other tweaks here & there.

Andy