[Xmltv-devel] Time for a release?

[Nick Morrott]

First things first - a happy new year to all XMLTV users and developers!

How does everyone feel about releasing 0.5.69 in the next couple of weeks?

There have been some important changes and additions to the project
since the release of 0.5.68 in mid-2016, which would be great to make
available generally.

More specifically, I'm acutely aware of the approaching deadline
(February 5th 2017) to get updated software packages into "Stretch",
the newest version of the Debian GNU/Linux distribution. Debian stable
users are currently using XMLTV version 0.5.63!

In order to be included in the next Debian stable release, software
packages must be uploaded *at least 10 days in advance* to ensure they
migrate into the Debian testing repository before the deadline.

I have some Augment issues and testing I would like to look at over
the next week, and there is some outstanding tv_grab_huro breakage
that would be great to fix before a new release.

Are there other issues that should try to address before a release?

Looking at possible dates, the latest I would want to have a release
would be Sun 22nd January, giving 14 days before the Debian freeze.
Sun 15th is another possibility, but that's only 10 days away. And
both of these dates assume Robert is available to push a release out.

Thoughts?

Cheers,
Nick

[Robert Eden]

Post by Nick Morrott
How does everyone feel about releasing 0.5.69 in the next couple of weeks?

Happy New Year to you too! Sounds good to me.. it's been a while.

Post by Nick Morrott
Are there other issues that should try to address before a release?

What about renaming tv_grab_sd_json to tv_grab_zz_sdjson ? IIRC that
was the consensus to avoid
confusing folks in the pissing off Sudan, correct?

This release will also have tv_grab_zz_sdjson_sqlite

I'm good any time after this weekend.

Anyone ever hear from Chris Butler? I haven't been able to get hold of him.

Robert

[Gary Buhrmaster]

On Thu, Jan 5, 2017 at 4:09 PM, Robert Eden <***@gmail.com> wrote:
....

Post by Robert Eden
What about renaming tv_grab_sd_json to tv_grab_zz_sdjson ? IIRC that
was the consensus to avoid
confusing folks in the pissing off Sudan, correct?

For one (and only one?) release I would recommend
providing a program called tv_grab_sd_json that warns
that the grabber has been renamed, and tries to invoke
the new name (which may or may not be successful,
but at least should TRY to get people to change, and
might avoid people using the old program by accident
depending on how they extract the distribution files).

Something similar to what I did for my grabber rename at:

https://github.com/garybuhrmaster/tv_grab_zz_sdjson_sqlite/blob/master/tv_grab_na_sd

I would presume that would be up to Kevin, of course.

[Kevin Groeneveld]

Post by Gary Buhrmaster
....

Post by Robert Eden
What about renaming tv_grab_sd_json to tv_grab_zz_sdjson ? IIRC that
was the consensus to avoid
confusing folks in the pissing off Sudan, correct?

For one (and only one?) release I would recommend
providing a program called tv_grab_sd_json that warns
that the grabber has been renamed, and tries to invoke
the new name (which may or may not be successful,
but at least should TRY to get people to change, and
might avoid people using the old program by accident
depending on how they extract the distribution files).
https://github.com/garybuhrmaster/tv_grab_zz_sdjson_sqlite/blob/master/tv_
grab_na_sd

I agree there needs to be some migration aid. How has this been handled in
the past?

I have noticed that sub filename in grab/Config_file.pm has a parameter
"old_progname" to help with renaming conf files. But I never call this sub
directly but just use ParseOptions from XMLTV::Options for which there
doesn't seem to be a way to utilize this feature?

Using something like the code Gary linked to on his github seems okay to
me. Does this code work on windows?

Post by Gary Buhrmaster
I would presume that would be up to Kevin, of course.

Robert previously suggested he could move/rename the file on the CVS server
to maintain the history. I am not sure if that is the best method but if
that is the way we proceed then it may be easiest to let Robert handle the
whole rename process including updating makefiles and leaving a migration
script in place. He is probably also in a better position to know what is
going to work on Windows than I am.


Kevin

[Gary Buhrmaster]

Using something like the code Gary linked to on his github seems okay to me.
Does this code work on windows?

I have no idea, but if it does not, and someone knows
why, please let me know if there is a code fragment
that will work on Windows so I could update the
code fragment before I finally mark it as deleted
(for my purposes, in that repo, its time has come to
a middle).

Robert previously suggested he could move/rename the file on the CVS server
to maintain the history. I am not sure if that is the best method ....

With cvs there is no nice way to rename an entire
directory and maintain history. You can move
individual files using the rename command, but a
common approach when renaming a directory is
server manipulations and then a few client side
commits to (try to) insure that the new and the old
revisions (with the new/old names) continue to work.
A better way forward long term is likely moving to git
(or for this specific case, even svn will do), but I am
going to guess that there is not a strong consensus
to moving to a more modern version control system
in this community (at least not today).

[Nick Morrott]

Post by Robert Eden

Post by Nick Morrott
How does everyone feel about releasing 0.5.69 in the next couple of weeks?

Happy New Year to you too! Sounds good to me.. it's been a while.

Post by Nick Morrott
Are there other issues that should try to address before a release?

What about renaming tv_grab_sd_json to tv_grab_zz_sdjson ? IIRC that
was the consensus to avoid
confusing folks in the pissing off Sudan, correct?

We don't seem to have nailed down a technical solution yet for the
rename handling. From my perspective, a CVS rename with end-user
notification in the updated Debian package is one way of achieving the
rename.

Of course, we can let it go for this release and get something more
concrete in place post-release, but that will likely mean more users
inconvenienced later on.

Post by Robert Eden
This release will also have tv_grab_zz_sdjson_sqlite

Keen to get this grabber into the hands of regular Debian users.

Post by Robert Eden
I'm good any time after this weekend.

Sadly time has marched on without me :( Not a great time to be
disabled with flu and bronchitis, but I'm somewhat functioning now.
The need to get the release out ASAP is high, with just 14 days before
the Debian Stretch freeze on Feb 5th.

@Robert: We really need a release in the next day or two.

Post by Robert Eden
Anyone ever hear from Chris Butler? I haven't been able to get hold of him.

Have just heard once some months back - he's had no time for XMLTV for
quite some time. In addition to picking up the Debian packaging for
XMLTV I am also intending to replicate his testing framework locally
to keep track of grabber status across the Debian suite.


Here are the results of a run of all grabbers overnight from CVS HEAD:


Tested:
-------
tv_grab_ar ok
tv_grab_ch_search ok
tv_grab_combiner ok
tv_grab_dk_dr ok
tv_grab_dtv_la ok
tv_grab_es_laguiatv ok
tv_grab_eu_dotmedia ok
tv_grab_eu_egon channelnoprogramme
tv_grab_fi sorterror, notadditive
tv_grab_fi_sv ok
tv_grab_fr notadditive
tv_grab_fr_kazer ok
tv_grab_hr graberror
tv_grab_huro graberror
tv_grab_il ok
tv_grab_is channelnoprogramme
tv_grab_it ok
tv_grab_na_dtv ok
tv_grab_na_tvmedia notvalid
tv_grab_nl ok
tv_grab_pt graberror
tv_grab_pt_meo ok
tv_grab_se_swedb ok
tv_grab_se_tvzon ok
tv_grab_tr ok
tv_grab_uk_atlas notquiet, noprogrammes
tv_grab_uk_bleb ok
tv_grab_uk_tvguide ok


Failures were seen in

tv_grab_hr graberror
tv_grab_huro graberror
tv_grab_pt graberror


These will need to be disabled if the errors are fatal (will look in
more detail later, aware of recent reports of failures with _huro).

I am also wondering if _uk_atlas needs to be disabled. It seems any
use of it is in breach of the metabroadcast terms and conditions, and
users have had their API keys rejected based on its use.

@Geoff: any thoughts?

Cheers,
Nick

[Geoff Westcott]

On Sun, 22 Jan 2017 15:17:00 +0000, Nick Morrott wrote:

[...]

Post by Nick Morrott
I am also wondering if _uk_atlas needs to be disabled. It seems any
use of it is in breach of the metabroadcast terms and conditions, and
users have had their API keys rejected based on its use.
@Geoff: any thoughts?

Hi Nick,

I've been musing over this one for some time. *In theory* someone could take out a paid sub with MB and then use the grabber legally. In practice I think that is unlikely. The alternative is to grab <24 hours of data, but even here the T&C are probably broken by using it.

I think, on balance, it should probably be retired. To avoid misleading people if nothing else.

Cheers,
Geoff

[Robert Eden]

Post by Nick Morrott
Sadly time has marched on without me :( Not a great time to be
disabled with flu and bronchitis, but I'm somewhat functioning now.
The need to get the release out ASAP is high, with just 14 days before
the Debian Stretch freeze on Feb 5th.
@Robert: We really need a release in the next day or two.

Ok... My bad on the tv_grab_sd_json rename. I've been swamped...

I've read up on CVS rename and think the best plan is just create a new
file with the comment to look at the old name if you want any history.
Folks really don't look back anyway.

I'll find the time to add a comment to SD_JSON and copy it to the new
name tonight.

I'll also scan through the "broken" grabbers and make sure they're
really broken.

Based on Geoff's response, Atlas should be removed. :(

Last call for objections before a late Monday release!

Robert

[Robert Eden]

Ok, I just worked on this a bit..

tv_grab_zz_sdjson - added grabber
tv_grab_sd_json - added warning
tv_grab_hr - removed (target site gone)
tv_grab_huro - only works (a bit) for Slovakia (Hungry and Romania fail)
tv_grab_pt - removed - (broken due to site changes)

Changes committed and alpha-exe updated.

release pending Monday night unless objections raised.

[Nick Morrott]

On 22 Jan 2017 9:13 pm, "Robert Eden" <***@gmail.com> wrote:

Ok, I just worked on this a bit..

tv_grab_zz_sdjson - added grabber
tv_grab_sd_json - added warning
tv_grab_hr - removed (target site gone)
tv_grab_huro - only works (a bit) for Slovakia (Hungry and Romania fail)
tv_grab_pt - removed - (broken due to site changes)

Changes committed and alpha-exe updated.

release pending Monday night unless objections raised.


Thanks Robert!

Nick

[Karl Dietz]

Post by Nick Morrott
-------
tv_grab_eu_egon channelnoprogramme

I'm slowly ending maintenance of the feed for _eu_egon

Post by Nick Morrott
tv_grab_eu_dotmedia ok

all channels are also available from _eu_dotmedia (xmltv.se)
I'm not sure I can add the warning until release later today, so if
someone can add it that would be appreciated.

Post by Nick Morrott
I am also wondering if _uk_atlas needs to be disabled. It seems any
use of it is in breach of the metabroadcast terms and conditions, and
users have had their API keys rejected based on its use.

Upstream was pretty clear on what their wishes are for consumers of
their API... I'd say implement the (small) needed change or remove the
grabber from active distribution.

Regards,
Karl