Re: Time for a release?

Nick Morrott <[email protected]> Sun, 22 Jan 2017 15:17:00 +0000
Newsgroups gmane.comp.tv.xmltv.devel
Message-ID <CAOQWjw0oR86SPUqS6qe__L4Lfk30KyvHT7GYOvjCDhjmm42akA@mail.gmail.com>
On 5 January 2017 at 16:09, Robert Eden <[email protected]> wrote:
> On 1/5/2017 9:54 AM, Nick Morrott wrote:
>> 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.
>> 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.

> This release will also have tv_grab_zz_sdjson_sqlite

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

> 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.

> 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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot