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