[RFC] Initial scan files troubles and brainstorming

[RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

Hello list,

I was talking to someone over at tvheadend and was told that the 
linux-media initial scan files tend to be often very out dated. Also 
when newer files are submitted, requests to merge them are simply being 
ignored. Obviously I have zero proof to back those claims. True or not, 
they have decided to keep a local copy and try to keep that up to date 
as possible. One of the reasons to take this approach, is because major 
distro's also do it in this way.

This obviously results in a duplication of work and since it's factual 
data really wasted resources, no central repository of said factual 
data, but spread and makes it confusing on top of that for users of this 
data.

Now I don't know the proper solution or if it really is a problem. Well 
it appears to be so I guess ;)

Something that comes to mind, is to split off the initial scan files 
from the dvb-apps package and have a seperate git tree for it, like for 
example the firmware git tree. I feel this has several advantages over 
the current setup.

One could have /usr/share/dvb/ as a git tree and simply pull to have an 
up to date tree.
Initialscan file 'users (as in developers)' can more easily clone it and 
do pull requests.
Possibly more lenient commit access, e.g. allow a 'trusted' developer of 
a dvb project to have commit rights, without much risk of breaking any 
source code.
Other things I haven't thought of yet.
Since there really isn't a 'stable' release, current trunk can be 
considered the go to release, unverified changes could live in a branch?

Again, if everybody can firmly claim there is no problem and that the 
initial scanfiles are updated nearly when an actually change takes 
place, then we should try convince downstream maintainers of course.

Anyway, this is just something that was on my mind and wanted some 
feedback on.

Oliver

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

Unfortunatly, I have had zero replies.

So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us 
with updated polish DVB-T frequencies for his region. This has yet to be 
merged, almost 3 weeks later.

While I know people are busy and merging frequency updates doesn't seem 
critical, for people who somewhat depend on them, the sooner, the better.

Since I didn't expect anybody to actually do the work, just was asking 
for your thoughts, I've done the work. I've setup a repository and 
purged all unrelated files. All history should have been preserved.

I'll quickly repeat why I think this approach would be quite reasonable.

* dvb-apps binary changes don't result in unnecessary releases
* frequency updates don't result in unnecessary dvb-app releases
* Less strict requirements for commits (code reviews etc)
* Possibly easier entry for new submitters
* much easier to package (tag it once per month if an update was)
* Separate maintainer possible
* just seems more logical to have it separated ;)

This obviously should find a nice home on linuxtv where it belongs!

Here is my personal repository with the work I mentioned done.
git://git.schinagl.nl/dvb_frequency_scanfiles.git

If an issue is that none of the original maintainers are not looking 
forward to do the job, I am willing to take maintenance on me for now.

Anyway, hopefully this time we can get some form of discussion going :)

Oliver

On 10/18/12 13:26, Oliver Schinagl wrote:
> Hello list,
>
> I was talking to someone over at tvheadend and was told that the
> linux-media initial scan files tend to be often very out dated. Also
> when newer files are submitted, requests to merge them are simply being
> ignored. Obviously I have zero proof to back those claims. True or not,
> they have decided to keep a local copy and try to keep that up to date
> as possible. One of the reasons to take this approach, is because major
> distro's also do it in this way.
> 1
> This obviously results in a duplication of work and since it's factual
> data really wasted resources, no central repository of said factual
> data, but spread and makes it confusing on top of that for users of this
> data.
>
> Now I don't know the proper solution or if it really is a problem. Well
> it appears to be so I guess ;)
>
> Something that comes to mind, is to split off the initial scan files
> from the dvb-apps package and have a seperate git tree for it, like for
> example the firmware git tree. I feel this has several advantages over
> the current setup.
>
> One could have /usr/share/dvb/ as a git tree and simply pull to have an
> up to date tree.
> Initialscan file 'users (as in developers)' can more easily clone it and
> do pull requests.
> Possibly more lenient commit access, e.g. allow a 'trusted' developer of
> a dvb project to have commit rights, without much risk of breaking any
> source code.
> Other things I haven't thought of yet.
> Since there really isn't a 'stable' release, current trunk can be
> considered the go to release, unverified changes could live in a branch?
>
> Again, if everybody can firmly claim there is no problem and that the
> initial scanfiles are updated nearly when an actually change takes
> place, then we should try convince downstream maintainers of course.
>
> Anyway, this is just something that was on my mind and wanted some
> feedback on.
>
> Oliver
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 19-12-12 00:23, Jonathan McCrohan wrote:
> Hi Oliver,
>
> On 18/12/12 22:01, Oliver Schinagl wrote:
>> Unfortunatly, I have had zero replies.
> Apologies. I wasn't subscribed to linux-media. I am now.
>
>> So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us
>> with updated polish DVB-T frequencies for his region. This has yet to be
>> merged, almost 3 weeks later.
>>
>> While I know people are busy and merging frequency updates doesn't seem
>> critical, for people who somewhat depend on them, the sooner, the better.
> I can relate. I currently have two patch files that I am trying to get
> merged myself I have been contacting Manu and Christoph) directly
> because previous attempts at posting to linux-media were left unattended
> for a good period of time.
>
>> I'll quickly repeat why I think this approach would be quite reasonable.
>>
>> * dvb-apps binary changes don't result in unnecessary releases
>> * frequency updates don't result in unnecessary dvb-app releases
>> * Less strict requirements for commits (code reviews etc)
>> * Possibly easier entry for new submitters
>> * much easier to package (tag it once per month if an update was)
>> * Separate maintainer possible
>> * just seems more logical to have it separated ;)
>>
>> This obviously should find a nice home on linuxtv where it belongs!
> I like this approach, but I'm afraid that decoupling dvb-apps and scan
> files may result in distributions paying less attention to scan files.
> At the moment, they are forced to update the scan files when a new
> release of dvb-apps appears.
So if no code changes are needed/done, but scan files are updated, a new 
dvb-apps release needs to be made?

That also results in grief for packagers. Packages need to be made but 
more importantly tested against many combinations. While the changes 
(binary anyway) would be trivial/non-existant, it would result in 
annoyance for packagers and could even be ignored.

scanfiles could be packaged and released just as easily and since there 
are applications already out there, that do not even use or need 
dvb-apps, it makes sense to seperate them. TVheadend for example does 
not need dvb-apps in any form and i'm sure there's more.

So it goes both ways :p
>
>> If an issue is that none of the original maintainers are not looking
>> forward to do the job, I am willing to take maintenance on me for now.
> To be honest, I think the current system works okay. I think more people
> just need to be given hg commit access. This would solve the current delays.
>
> Jon
>

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
> Unfortunatly, I have had zero replies.

Hmm, it's sad there is a silence in this thread from linux-media guys :/.

> So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us
> with updated polish DVB-T frequencies for his region. This has yet to be
> merged, almost 3 weeks later.

I sent a patch for cz data too:
https://patchwork.kernel.org/patch/1844201/

> I'll quickly repeat why I think this approach would be quite reasonable.
> 
> * dvb-apps binary changes don't result in unnecessary releases
> * frequency updates don't result in unnecessary dvb-app releases
> * Less strict requirements for commits (code reviews etc)

Well the code should be reviewed still. See commit a2e96055db297 in your
repo, it's bogus. The freq added is in kHz instead of MHz.

> * Possibly easier entry for new submitters
> * much easier to package (tag it once per month if an update was)
> * Separate maintainer possible
> * just seems more logical to have it separated ;)

The downside is you have to change the URL in kaffeine sources as
kaffeine generates its scan file from that repo (on the server side and
the client downloads then http://kaffeine.kde.org/scanfile.dvb.qz).

> This obviously should find a nice home on linuxtv where it belongs!

At best.

> Here is my personal repository with the work I mentioned done.
> git://git.schinagl.nl/dvb_frequency_scanfiles.git
> 
> If an issue is that none of the original maintainers are not looking
> forward to do the job, I am willing to take maintenance on me for now.

Ping? Anybody? I would help with that too as I hate resending patches.
But the first step I would do is a conversion to GIT. HG is demented to
begin with.

-- 
js

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 07-01-13 11:46, Jiri Slaby wrote:
> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>> Unfortunatly, I have had zero replies.
> Hmm, it's sad there is a silence in this thread from linux-media guys :/.
In their defense, they are very very busy people ;) chatter on this 
thread does bring it up however.
>
>> So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us
>> with updated polish DVB-T frequencies for his region. This has yet to be
>> merged, almost 3 weeks later.
> I sent a patch for cz data too:
> https://patchwork.kernel.org/patch/1844201/
I see that patch lives on the kernel patchwork not the linuxtv one. Did 
it pass this ML? I have applied it to my tree for now.
>
>> I'll quickly repeat why I think this approach would be quite reasonable.
>>
>> * dvb-apps binary changes don't result in unnecessary releases
>> * frequency updates don't result in unnecessary dvb-app releases
>> * Less strict requirements for commits (code reviews etc)
> Well the code should be reviewed still. See commit a2e96055db297 in your
> repo, it's bogus. The freq added is in kHz instead of MHz.
You are absolutely right, on both accounts. But its far less important. 
Yes I committed it wrongfully. I missed it. I should have spotted it. 
You 'fixed' this bug though ;) Reviewing is still needed. 'Rules' in 
that regard can always be brought up later, when things actually do 
change. Auto apply after a week for example?

Again, 'bugs' aren't critical and don't break functionality (but of 
course do cause headaches if they don't work). But updates are required 
to happen quickly if they do (for dvb-t at the very least). If the 
broadcaster changes settings, users probably want to be able to tune 
right away.
>
>> * Possibly easier entry for new submitters
>> * much easier to package (tag it once per month if an update was)
>> * Separate maintainer possible
>> * just seems more logical to have it separated ;)
> The downside is you have to change the URL in kaffeine sources as
> kaffeine generates its scan file from that repo (on the server side and
> the client downloads then http://kaffeine.kde.org/scanfile.dvb.qz).
IF a proper change goes through, then that's a one time change only 
though and while kaffeine can still use its own mirror, it's less needed :p
>
>> This obviously should find a nice home on linuxtv where it belongs!
> At best.
>
>> Here is my personal repository with the work I mentioned done.
>> git://git.schinagl.nl/dvb_frequency_scanfiles.git
>>
>> If an issue is that none of the original maintainers are not looking
>> forward to do the job, I am willing to take maintenance on me for now.
> Ping? Anybody? I would help with that too as I hate resending patches.
> But the first step I would do is a conversion to GIT. HG is demented to
> begin with.
>

Re: [RFC] Initial scan files troubles and brainstorming

[Johannes Stezenbach]

On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
> On 07-01-13 11:46, Jiri Slaby wrote:
> >On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
> >>Unfortunatly, I have had zero replies.
> >Hmm, it's sad there is a silence in this thread from linux-media guys :/.
> In their defense, they are very very busy people ;) chatter on this
> thread does bring it up however.

This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should
respond, but apparently there is no dvb-apps maintainer...
Maybe you should ask Mauro directly to create an account for you
to implement what you proposed.

Thanks,
Johannes

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 08-01-13 21:01, Johannes Stezenbach wrote:
> On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
>> On 07-01-13 11:46, Jiri Slaby wrote:
>>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>>>> Unfortunatly, I have had zero replies.
>>> Hmm, it's sad there is a silence in this thread from linux-media guys :/.
>> In their defense, they are very very busy people ;) chatter on this
>> thread does bring it up however.
> This is such a nice thing to say :-)
> But it might be that Mauro thinks the dvb-apps maintainer should
> respond, but apparently there is no dvb-apps maintainer...
> Maybe you should ask Mauro directly to create an account for you
> to implement what you proposed.
Mauro is CC'ed and I'd ask of course for this (I kinda did) but who 
decides what I suggested is a good idea? I personally obviously think it 
is ;) and even more so if dvb-apps are unmaintained.

I guess the question now becomes 'who okay's this change? Who says 
'okay, lets do it this way. Once that is answered we can go from there ;)

>
> Thanks,
> Johannes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Em Wed, 09 Jan 2013 10:43:23 +0100
Oliver Schinagl <oliver+list@schinagl.nl> escreveu:

> On 08-01-13 21:01, Johannes Stezenbach wrote:
> > On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
> >> On 07-01-13 11:46, Jiri Slaby wrote:
> >>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
> >>>> Unfortunatly, I have had zero replies.
> >>> Hmm, it's sad there is a silence in this thread from linux-media guys :/.
> >> In their defense, they are very very busy people ;) chatter on this
> >> thread does bring it up however.
> > This is such a nice thing to say :-)
> > But it might be that Mauro thinks the dvb-apps maintainer should
> > respond, but apparently there is no dvb-apps maintainer...
> > Maybe you should ask Mauro directly to create an account for you
> > to implement what you proposed.
> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who 
> decides what I suggested is a good idea? I personally obviously think it 
> is ;) and even more so if dvb-apps are unmaintained.
> 
> I guess the question now becomes 'who okay's this change? Who says 
> 'okay, lets do it this way. Once that is answered we can go from there ;)

If I understood it right, you want to split the scan files into a separate
git tree and maintain it, right?

I'm ok with that.

Regards,
Mauro

Re: [RFC] Initial scan files troubles and brainstorming

[Michael Krufky]

On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em Wed, 09 Jan 2013 10:43:23 +0100
> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>
>> On 08-01-13 21:01, Johannes Stezenbach wrote:
>> > On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
>> >> On 07-01-13 11:46, Jiri Slaby wrote:
>> >>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>> >>>> Unfortunatly, I have had zero replies.
>> >>> Hmm, it's sad there is a silence in this thread from linux-media guys :/.
>> >> In their defense, they are very very busy people ;) chatter on this
>> >> thread does bring it up however.
>> > This is such a nice thing to say :-)
>> > But it might be that Mauro thinks the dvb-apps maintainer should
>> > respond, but apparently there is no dvb-apps maintainer...
>> > Maybe you should ask Mauro directly to create an account for you
>> > to implement what you proposed.
>> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
>> decides what I suggested is a good idea? I personally obviously think it
>> is ;) and even more so if dvb-apps are unmaintained.
>>
>> I guess the question now becomes 'who okay's this change? Who says
>> 'okay, lets do it this way. Once that is answered we can go from there ;)
>
> If I understood it right, you want to split the scan files into a separate
> git tree and maintain it, right?
>
> I'm ok with that.
>
> Regards,
> Mauro

As a DVB maintainer, I am OK with this as well - It does indeed make
sense to separate the c code sources from the regional frequency
tables, and I'm sure we'll see much benefit from this change.

Regards,

Mike Krufky

Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Em Wed, 9 Jan 2013 06:08:44 -0500
Michael Krufky <mkrufky@linuxtv.org> escreveu:

> On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
> > Em Wed, 09 Jan 2013 10:43:23 +0100
> > Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
> >
> >> On 08-01-13 21:01, Johannes Stezenbach wrote:
> >> > On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
> >> >> On 07-01-13 11:46, Jiri Slaby wrote:
> >> >>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
> >> >>>> Unfortunatly, I have had zero replies.
> >> >>> Hmm, it's sad there is a silence in this thread from linux-media guys :/.
> >> >> In their defense, they are very very busy people ;) chatter on this
> >> >> thread does bring it up however.
> >> > This is such a nice thing to say :-)
> >> > But it might be that Mauro thinks the dvb-apps maintainer should
> >> > respond, but apparently there is no dvb-apps maintainer...
> >> > Maybe you should ask Mauro directly to create an account for you
> >> > to implement what you proposed.
> >> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
> >> decides what I suggested is a good idea? I personally obviously think it
> >> is ;) and even more so if dvb-apps are unmaintained.
> >>
> >> I guess the question now becomes 'who okay's this change? Who says
> >> 'okay, lets do it this way. Once that is answered we can go from there ;)
> >
> > If I understood it right, you want to split the scan files into a separate
> > git tree and maintain it, right?
> >
> > I'm ok with that.
> >
> > Regards,
> > Mauro
> 
> As a DVB maintainer, I am OK with this as well - It does indeed make
> sense to separate the c code sources from the regional frequency
> tables, and I'm sure we'll see much benefit from this change.

Done. I created a tree for Oliver to maintain it and an account for him.
I also created a new tree with just the DVB table commits to:
	http://git.linuxtv.org/dtv-scan-tables.git

I kept there both szap and scan files, although maybe it makes sense to
drop the szap table (channels-conf dir). It also makes sense to drop the
tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid troubles
on distros that may want to have both packages.

Anyway, as Oliver has now access to both trees, I'll let him to handle
and maintain it.

Christoph,

Thank you for all the hard work over all those years!

Happy new year,
Mauro

kaffeine.kde.org/scanfile.dvb.qz is obsolete [was: [RFC] Initial scan files troubles and brainstorming]

[Jiri Slaby]

On 01/09/2013 03:41 PM, Mauro Carvalho Chehab wrote:
> Christoph,
> 
> Thank you for all the hard work over all those years!

Yeah, I second this.

I have a note though. Who is going to fix the URL in kaffeine? And how
often is kaffeine.kde.org/scanfile.dvb.qz updated? Is this done
automatically? As it is pretty outdated (9/2011), I don't think it is...
Should this be moved somewhere else?

thanks,
-- 
js

Re: kaffeine.kde.org/scanfile.dvb.qz is obsolete [was: [RFC] Initial scan files troubles and brainstorming]

[Christoph Pfister]

2013/1/9 Jiri Slaby <jirislaby@gmail.com>:
> On 01/09/2013 03:41 PM, Mauro Carvalho Chehab wrote:
>> Christoph,
>>
>> Thank you for all the hard work over all those years!
>
> Yeah, I second this.
>
> I have a note though. Who is going to fix the URL in kaffeine?

That belongs to me.

> And how
> often is kaffeine.kde.org/scanfile.dvb.qz updated? Is this done
> automatically?

No, upload happens manually. I will take care of an update.

> As it is pretty outdated (9/2011), I don't think it is...
> Should this be moved somewhere else?
>
> thanks,
> --
> js

Christoph

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/9/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em Wed, 9 Jan 2013 06:08:44 -0500
> Michael Krufky <mkrufky@linuxtv.org> escreveu:
>
>> On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>> > Em Wed, 09 Jan 2013 10:43:23 +0100
>> > Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>> >
>> >> On 08-01-13 21:01, Johannes Stezenbach wrote:
>> >> > On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
>> >> >> On 07-01-13 11:46, Jiri Slaby wrote:
>> >> >>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>> >> >>>> Unfortunatly, I have had zero replies.
>> >> >>> Hmm, it's sad there is a silence in this thread from linux-media
>> >> >>> guys :/.
>> >> >> In their defense, they are very very busy people ;) chatter on this
>> >> >> thread does bring it up however.
>> >> > This is such a nice thing to say :-)
>> >> > But it might be that Mauro thinks the dvb-apps maintainer should
>> >> > respond, but apparently there is no dvb-apps maintainer...
>> >> > Maybe you should ask Mauro directly to create an account for you
>> >> > to implement what you proposed.
>> >> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
>> >> decides what I suggested is a good idea? I personally obviously think
>> >> it
>> >> is ;) and even more so if dvb-apps are unmaintained.
>> >>
>> >> I guess the question now becomes 'who okay's this change? Who says
>> >> 'okay, lets do it this way. Once that is answered we can go from there
>> >> ;)
>> >
>> > If I understood it right, you want to split the scan files into a
>> > separate
>> > git tree and maintain it, right?
>> >
>> > I'm ok with that.
>> >
>> > Regards,
>> > Mauro
>>
>> As a DVB maintainer, I am OK with this as well - It does indeed make
>> sense to separate the c code sources from the regional frequency
>> tables, and I'm sure we'll see much benefit from this change.
>
> Done. I created a tree for Oliver to maintain it and an account for him.
> I also created a new tree with just the DVB table commits to:
> 	http://git.linuxtv.org/dtv-scan-tables.git
>
> I kept there both szap and scan files, although maybe it makes sense to
> drop the szap table (channels-conf dir). It also makes sense to drop the
> tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid

Being one of the maintainers:

I will keep the tables in the dvb-apps tree for the time being. Will decide to
drop the config files as needed from dvb-apps. It is necessary to keep a
copy of the config files for development purposes, rather than pulling from
different trees.


Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 01/10/2013 06:40 PM, Manu Abraham wrote:
> On 1/9/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>> Em Wed, 9 Jan 2013 06:08:44 -0500
>> Michael Krufky <mkrufky@linuxtv.org> escreveu:
>>
>>> On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Em Wed, 09 Jan 2013 10:43:23 +0100
>>>> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>>>>
>>>>> On 08-01-13 21:01, Johannes Stezenbach wrote:
>>>>>> On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
>>>>>>> On 07-01-13 11:46, Jiri Slaby wrote:
>>>>>>>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>>>>>>>>> Unfortunatly, I have had zero replies.
>>>>>>>> Hmm, it's sad there is a silence in this thread from linux-media
>>>>>>>> guys :/.
>>>>>>> In their defense, they are very very busy people ;) chatter on this
>>>>>>> thread does bring it up however.
>>>>>> This is such a nice thing to say :-)
>>>>>> But it might be that Mauro thinks the dvb-apps maintainer should
>>>>>> respond, but apparently there is no dvb-apps maintainer...
>>>>>> Maybe you should ask Mauro directly to create an account for you
>>>>>> to implement what you proposed.
>>>>> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
>>>>> decides what I suggested is a good idea? I personally obviously think
>>>>> it
>>>>> is ;) and even more so if dvb-apps are unmaintained.
>>>>>
>>>>> I guess the question now becomes 'who okay's this change? Who says
>>>>> 'okay, lets do it this way. Once that is answered we can go from there
>>>>> ;)
>>>>
>>>> If I understood it right, you want to split the scan files into a
>>>> separate
>>>> git tree and maintain it, right?
>>>>
>>>> I'm ok with that.
>>>>
>>>> Regards,
>>>> Mauro
>>>
>>> As a DVB maintainer, I am OK with this as well - It does indeed make
>>> sense to separate the c code sources from the regional frequency
>>> tables, and I'm sure we'll see much benefit from this change.
>>
>> Done. I created a tree for Oliver to maintain it and an account for him.
>> I also created a new tree with just the DVB table commits to:
>> 	http://git.linuxtv.org/dtv-scan-tables.git
>>
>> I kept there both szap and scan files, although maybe it makes sense to
>> drop the szap table (channels-conf dir). It also makes sense to drop the
>> tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid
> 
> Being one of the maintainers:
> 
> I will keep the tables in the dvb-apps tree for the time being.

That does not make sense at all -- why? Duplicated stuff always hurts.

> Will decide to
> drop the config files as needed from dvb-apps. It is necessary to keep a
> copy of the config files for development purposes, rather than pulling from
> different trees.

What development purposes, could you be more specific? You can still use
git submodules if really needed. But as it stands I do not see a reason
for that at all...

regards,
-- 
js

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 01/10/2013 06:40 PM, Manu Abraham wrote:
>> On 1/9/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>>> Em Wed, 9 Jan 2013 06:08:44 -0500
>>> Michael Krufky <mkrufky@linuxtv.org> escreveu:
>>>
>>>> On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
>>>> <mchehab@redhat.com> wrote:
>>>>> Em Wed, 09 Jan 2013 10:43:23 +0100
>>>>> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>>>>>
>>>>>> On 08-01-13 21:01, Johannes Stezenbach wrote:
>>>>>>> On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
>>>>>>>> On 07-01-13 11:46, Jiri Slaby wrote:
>>>>>>>>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>>>>>>>>>> Unfortunatly, I have had zero replies.
>>>>>>>>> Hmm, it's sad there is a silence in this thread from linux-media
>>>>>>>>> guys :/.
>>>>>>>> In their defense, they are very very busy people ;) chatter on this
>>>>>>>> thread does bring it up however.
>>>>>>> This is such a nice thing to say :-)
>>>>>>> But it might be that Mauro thinks the dvb-apps maintainer should
>>>>>>> respond, but apparently there is no dvb-apps maintainer...
>>>>>>> Maybe you should ask Mauro directly to create an account for you
>>>>>>> to implement what you proposed.
>>>>>> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
>>>>>> decides what I suggested is a good idea? I personally obviously think
>>>>>> it
>>>>>> is ;) and even more so if dvb-apps are unmaintained.
>>>>>>
>>>>>> I guess the question now becomes 'who okay's this change? Who says
>>>>>> 'okay, lets do it this way. Once that is answered we can go from
>>>>>> there
>>>>>> ;)
>>>>>
>>>>> If I understood it right, you want to split the scan files into a
>>>>> separate
>>>>> git tree and maintain it, right?
>>>>>
>>>>> I'm ok with that.
>>>>>
>>>>> Regards,
>>>>> Mauro
>>>>
>>>> As a DVB maintainer, I am OK with this as well - It does indeed make
>>>> sense to separate the c code sources from the regional frequency
>>>> tables, and I'm sure we'll see much benefit from this change.
>>>
>>> Done. I created a tree for Oliver to maintain it and an account for him.
>>> I also created a new tree with just the DVB table commits to:
>>> 	http://git.linuxtv.org/dtv-scan-tables.git
>>>
>>> I kept there both szap and scan files, although maybe it makes sense to
>>> drop the szap table (channels-conf dir). It also makes sense to drop the
>>> tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid
>>
>> Being one of the maintainers:
>>
>> I will keep the tables in the dvb-apps tree for the time being.
>
> That does not make sense at all -- why? Duplicated stuff always hurts.


The scan files and config files are very specific to dvb-apps, some
applications
do rely on these config files. It doesn't really make sense to have
split out config
files for these  small applications.


>
>> Will decide to
>> drop the config files as needed from dvb-apps. It is necessary to keep a
>> copy of the config files for development purposes, rather than pulling
>> from
>> different trees.
>
> What development purposes, could you be more specific? You can still use
> git submodules if really needed. But as it stands I do not see a reason
> for that at all...


Did you think that the dvb-apps just came out of thin air ?

development of dvb-applications, implies eventually config files also
will be updated as necessary. Having them in separate repositories
makes such work harder for working.
while working with dvb-apps, it would make things saner if it is the
same SCM, rather
than having different SCM's. So according to you, you want to make it
still harder for someone to work with dvb-apps.


Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Michael Krufky]

On Thu, Jan 10, 2013 at 1:46 PM, Manu Abraham <abraham.manu@gmail.com> wrote:
> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>> On 01/10/2013 06:40 PM, Manu Abraham wrote:
>>> On 1/9/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>>>> Em Wed, 9 Jan 2013 06:08:44 -0500
>>>> Michael Krufky <mkrufky@linuxtv.org> escreveu:
>>>>
>>>>> On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
>>>>> <mchehab@redhat.com> wrote:
>>>>>> Em Wed, 09 Jan 2013 10:43:23 +0100
>>>>>> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>>>>>>
>>>>>>> On 08-01-13 21:01, Johannes Stezenbach wrote:
>>>>>>>> On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
>>>>>>>>> On 07-01-13 11:46, Jiri Slaby wrote:
>>>>>>>>>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>>>>>>>>>>> Unfortunatly, I have had zero replies.
>>>>>>>>>> Hmm, it's sad there is a silence in this thread from linux-media
>>>>>>>>>> guys :/.
>>>>>>>>> In their defense, they are very very busy people ;) chatter on this
>>>>>>>>> thread does bring it up however.
>>>>>>>> This is such a nice thing to say :-)
>>>>>>>> But it might be that Mauro thinks the dvb-apps maintainer should
>>>>>>>> respond, but apparently there is no dvb-apps maintainer...
>>>>>>>> Maybe you should ask Mauro directly to create an account for you
>>>>>>>> to implement what you proposed.
>>>>>>> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
>>>>>>> decides what I suggested is a good idea? I personally obviously think
>>>>>>> it
>>>>>>> is ;) and even more so if dvb-apps are unmaintained.
>>>>>>>
>>>>>>> I guess the question now becomes 'who okay's this change? Who says
>>>>>>> 'okay, lets do it this way. Once that is answered we can go from
>>>>>>> there
>>>>>>> ;)
>>>>>>
>>>>>> If I understood it right, you want to split the scan files into a
>>>>>> separate
>>>>>> git tree and maintain it, right?
>>>>>>
>>>>>> I'm ok with that.
>>>>>>
>>>>>> Regards,
>>>>>> Mauro
>>>>>
>>>>> As a DVB maintainer, I am OK with this as well - It does indeed make
>>>>> sense to separate the c code sources from the regional frequency
>>>>> tables, and I'm sure we'll see much benefit from this change.
>>>>
>>>> Done. I created a tree for Oliver to maintain it and an account for him.
>>>> I also created a new tree with just the DVB table commits to:
>>>>     http://git.linuxtv.org/dtv-scan-tables.git
>>>>
>>>> I kept there both szap and scan files, although maybe it makes sense to
>>>> drop the szap table (channels-conf dir). It also makes sense to drop the
>>>> tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid
>>>
>>> Being one of the maintainers:
>>>
>>> I will keep the tables in the dvb-apps tree for the time being.
>>
>> That does not make sense at all -- why? Duplicated stuff always hurts.
>
>
> The scan files and config files are very specific to dvb-apps, some
> applications
> do rely on these config files. It doesn't really make sense to have
> split out config
> files for these  small applications.
>
>
>>
>>> Will decide to
>>> drop the config files as needed from dvb-apps. It is necessary to keep a
>>> copy of the config files for development purposes, rather than pulling
>>> from
>>> different trees.
>>
>> What development purposes, could you be more specific? You can still use
>> git submodules if really needed. But as it stands I do not see a reason
>> for that at all...
>
>
> Did you think that the dvb-apps just came out of thin air ?
>
> development of dvb-applications, implies eventually config files also
> will be updated as necessary. Having them in separate repositories
> makes such work harder for working.
> while working with dvb-apps, it would make things saner if it is the
> same SCM, rather
> than having different SCM's. So according to you, you want to make it
> still harder for someone to work with dvb-apps.
>
>
> Manu

Manu,

I see great value in separating the history of the data files from the
code files.  If you really think this is such a terrible task for a
developer to have to pull from a second repository to fetch these data
files, then I find no reason why we couldn't script it such that
building the dvb-apps package would trigger the pull from the
additional repository.

I think that's a fair compromise.

Meanwhile, your argument is for developers.  Developers can handle
pulling from a separated tree for data files who shouldn't be clouding
the history of source code development, anyway.  Developers are indeed
used to dealing with multiple repositories, and if any developer
isn't, then now is the time to get with the program!

I think this change is a great idea, and I would hope that we'd all
agree on this, at least.

Best Regards,

Mike Krufky

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 01/10/2013 07:56 PM, Michael Krufky wrote:
> I see great value in separating the history of the data files from the
> code files.  If you really think this is such a terrible task for a
> developer to have to pull from a second repository to fetch these data
> files, then I find no reason why we couldn't script it such that
> building the dvb-apps package would trigger the pull from the
> additional repository.

(Or use submodules.)

-- 
js

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Michael Krufky <mkrufky@linuxtv.org> wrote:
> On Thu, Jan 10, 2013 at 1:46 PM, Manu Abraham <abraham.manu@gmail.com>
> wrote:
>> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>>> On 01/10/2013 06:40 PM, Manu Abraham wrote:
>>>> On 1/9/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>>>>> Em Wed, 9 Jan 2013 06:08:44 -0500
>>>>> Michael Krufky <mkrufky@linuxtv.org> escreveu:
>>>>>
>>>>>> On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
>>>>>> <mchehab@redhat.com> wrote:
>>>>>>> Em Wed, 09 Jan 2013 10:43:23 +0100
>>>>>>> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>>>>>>>
>>>>>>>> On 08-01-13 21:01, Johannes Stezenbach wrote:
>>>>>>>>> On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
>>>>>>>>>> On 07-01-13 11:46, Jiri Slaby wrote:
>>>>>>>>>>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>>>>>>>>>>>> Unfortunatly, I have had zero replies.
>>>>>>>>>>> Hmm, it's sad there is a silence in this thread from linux-media
>>>>>>>>>>> guys :/.
>>>>>>>>>> In their defense, they are very very busy people ;) chatter on
>>>>>>>>>> this
>>>>>>>>>> thread does bring it up however.
>>>>>>>>> This is such a nice thing to say :-)
>>>>>>>>> But it might be that Mauro thinks the dvb-apps maintainer should
>>>>>>>>> respond, but apparently there is no dvb-apps maintainer...
>>>>>>>>> Maybe you should ask Mauro directly to create an account for you
>>>>>>>>> to implement what you proposed.
>>>>>>>> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
>>>>>>>> decides what I suggested is a good idea? I personally obviously
>>>>>>>> think
>>>>>>>> it
>>>>>>>> is ;) and even more so if dvb-apps are unmaintained.
>>>>>>>>
>>>>>>>> I guess the question now becomes 'who okay's this change? Who says
>>>>>>>> 'okay, lets do it this way. Once that is answered we can go from
>>>>>>>> there
>>>>>>>> ;)
>>>>>>>
>>>>>>> If I understood it right, you want to split the scan files into a
>>>>>>> separate
>>>>>>> git tree and maintain it, right?
>>>>>>>
>>>>>>> I'm ok with that.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mauro
>>>>>>
>>>>>> As a DVB maintainer, I am OK with this as well - It does indeed make
>>>>>> sense to separate the c code sources from the regional frequency
>>>>>> tables, and I'm sure we'll see much benefit from this change.
>>>>>
>>>>> Done. I created a tree for Oliver to maintain it and an account for
>>>>> him.
>>>>> I also created a new tree with just the DVB table commits to:
>>>>>     http://git.linuxtv.org/dtv-scan-tables.git
>>>>>
>>>>> I kept there both szap and scan files, although maybe it makes sense
>>>>> to
>>>>> drop the szap table (channels-conf dir). It also makes sense to drop
>>>>> the
>>>>> tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid
>>>>
>>>> Being one of the maintainers:
>>>>
>>>> I will keep the tables in the dvb-apps tree for the time being.
>>>
>>> That does not make sense at all -- why? Duplicated stuff always hurts.
>>
>>
>> The scan files and config files are very specific to dvb-apps, some
>> applications
>> do rely on these config files. It doesn't really make sense to have
>> split out config
>> files for these  small applications.
>>
>>
>>>
>>>> Will decide to
>>>> drop the config files as needed from dvb-apps. It is necessary to keep
>>>> a
>>>> copy of the config files for development purposes, rather than pulling
>>>> from
>>>> different trees.
>>>
>>> What development purposes, could you be more specific? You can still use
>>> git submodules if really needed. But as it stands I do not see a reason
>>> for that at all...
>>
>>
>> Did you think that the dvb-apps just came out of thin air ?
>>
>> development of dvb-applications, implies eventually config files also
>> will be updated as necessary. Having them in separate repositories
>> makes such work harder for working.
>> while working with dvb-apps, it would make things saner if it is the
>> same SCM, rather
>> than having different SCM's. So according to you, you want to make it
>> still harder for someone to work with dvb-apps.
>>
>>
>> Manu
>
> Manu,
>
> I see great value in separating the history of the data files from the
> code files.  If you really think this is such a terrible task for a
> developer to have to pull from a second repository to fetch these data
> files, then I find no reason why we couldn't script it such that
> building the dvb-apps package would trigger the pull from the
> additional repository.
>
> I think that's a fair compromise.


 As someone who has long been working with dvb-apps, I see no value
in this, but just pain altogether. For people who have never worked with it,
they can say anything what they want, which makes no sense at all.


> Meanwhile, your argument is for developers.  Developers can handle
> pulling from a separated tree for data files who shouldn't be clouding
> the history of source code development, anyway.  Developers are indeed
> used to dealing with multiple repositories, and if any developer
> isn't, then now is the time to get with the program!


It isn't that way. Users have to deal with 2 repositories as well. Anyway,
the repository is not having that many developers to state that developers
can handle all the burden. It is just but the reverse.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 01/10/13 20:04, Manu Abraham wrote:
> On 1/11/13, Michael Krufky <mkrufky@linuxtv.org> wrote:
>> On Thu, Jan 10, 2013 at 1:46 PM, Manu Abraham <abraham.manu@gmail.com>
>> wrote:
>>> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>>>> On 01/10/2013 06:40 PM, Manu Abraham wrote:
>>>>> On 1/9/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>>>>>> Em Wed, 9 Jan 2013 06:08:44 -0500
>>>>>> Michael Krufky <mkrufky@linuxtv.org> escreveu:
>>>>>>
>>>>>>> On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
>>>>>>> <mchehab@redhat.com> wrote:
>>>>>>>> Em Wed, 09 Jan 2013 10:43:23 +0100
>>>>>>>> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>>>>>>>>
>>>>>>>>> On 08-01-13 21:01, Johannes Stezenbach wrote:
>>>>>>>>>> On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
>>>>>>>>>>> On 07-01-13 11:46, Jiri Slaby wrote:
>>>>>>>>>>>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>>>>>>>>>>>>> Unfortunatly, I have had zero replies.
>>>>>>>>>>>> Hmm, it's sad there is a silence in this thread from linux-media
>>>>>>>>>>>> guys :/.
>>>>>>>>>>> In their defense, they are very very busy people ;) chatter on
>>>>>>>>>>> this
>>>>>>>>>>> thread does bring it up however.
>>>>>>>>>> This is such a nice thing to say :-)
>>>>>>>>>> But it might be that Mauro thinks the dvb-apps maintainer should
>>>>>>>>>> respond, but apparently there is no dvb-apps maintainer...
>>>>>>>>>> Maybe you should ask Mauro directly to create an account for you
>>>>>>>>>> to implement what you proposed.
>>>>>>>>> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
>>>>>>>>> decides what I suggested is a good idea? I personally obviously
>>>>>>>>> think
>>>>>>>>> it
>>>>>>>>> is ;) and even more so if dvb-apps are unmaintained.
>>>>>>>>>
>>>>>>>>> I guess the question now becomes 'who okay's this change? Who says
>>>>>>>>> 'okay, lets do it this way. Once that is answered we can go from
>>>>>>>>> there
>>>>>>>>> ;)
>>>>>>>>
>>>>>>>> If I understood it right, you want to split the scan files into a
>>>>>>>> separate
>>>>>>>> git tree and maintain it, right?
>>>>>>>>
>>>>>>>> I'm ok with that.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mauro
>>>>>>>
>>>>>>> As a DVB maintainer, I am OK with this as well - It does indeed make
>>>>>>> sense to separate the c code sources from the regional frequency
>>>>>>> tables, and I'm sure we'll see much benefit from this change.
>>>>>>
>>>>>> Done. I created a tree for Oliver to maintain it and an account for
>>>>>> him.
>>>>>> I also created a new tree with just the DVB table commits to:
>>>>>>      http://git.linuxtv.org/dtv-scan-tables.git
>>>>>>
>>>>>> I kept there both szap and scan files, although maybe it makes sense
>>>>>> to
>>>>>> drop the szap table (channels-conf dir). It also makes sense to drop
>>>>>> the
>>>>>> tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid
>>>>>
>>>>> Being one of the maintainers:
>>>>>
>>>>> I will keep the tables in the dvb-apps tree for the time being.
>>>>
>>>> That does not make sense at all -- why? Duplicated stuff always hurts.
>>>
>>>
>>> The scan files and config files are very specific to dvb-apps, some
>>> applications
>>> do rely on these config files. It doesn't really make sense to have
>>> split out config
>>> files for these  small applications.
>>>
>>>
>>>>
>>>>> Will decide to
>>>>> drop the config files as needed from dvb-apps. It is necessary to keep
>>>>> a
>>>>> copy of the config files for development purposes, rather than pulling
>>>>> from
>>>>> different trees.
>>>>
>>>> What development purposes, could you be more specific? You can still use
>>>> git submodules if really needed. But as it stands I do not see a reason
>>>> for that at all...
>>>
>>>
>>> Did you think that the dvb-apps just came out of thin air ?
>>>
>>> development of dvb-applications, implies eventually config files also
>>> will be updated as necessary. Having them in separate repositories
>>> makes such work harder for working.
>>> while working with dvb-apps, it would make things saner if it is the
>>> same SCM, rather
>>> than having different SCM's. So according to you, you want to make it
>>> still harder for someone to work with dvb-apps.
>>>
>>>
>>> Manu
>>
>> Manu,
>>
>> I see great value in separating the history of the data files from the
>> code files.  If you really think this is such a terrible task for a
>> developer to have to pull from a second repository to fetch these data
>> files, then I find no reason why we couldn't script it such that
>> building the dvb-apps package would trigger the pull from the
>> additional repository.
>>
>> I think that's a fair compromise.
>
>
>   As someone who has long been working with dvb-apps, I see no value
> in this, but just pain altogether. For people who have never worked with it,
> they can say anything what they want, which makes no sense at all.
Well there are a few apps that do use the initial scanfile tree, but do 
not use any of the dvb-apps.

(tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)
>
>
>> Meanwhile, your argument is for developers.  Developers can handle
>> pulling from a separated tree for data files who shouldn't be clouding
>> the history of source code development, anyway.  Developers are indeed
>> used to dealing with multiple repositories, and if any developer
>> isn't, then now is the time to get with the program!
>
>
> It isn't that way. Users have to deal with 2 repositories as well. Anyway,
> the repository is not having that many developers to state that developers
> can handle all the burden. It is just but the reverse.
Well one of the biggest issues was, that the scanfiles where ill 
maintained and projects where working around those shortcommings.

The scanfiles are technically unrelated. They are data files, facts and 
can very logically live seperated :) Having commit messages pure for 
data files in a source tree just looks off.

They simply have become a seperate entity as people (not developers) 
depend on them. (Yes there is wscan of course).

Also, purely out of curiousity, how are the scanfiles used during 
development?

oliver

>
> Manu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Oliver Schinagl <oliver+list@schinagl.nl> wrote:
>> they can say anything what they want, which makes no sense at all.
> Well there are a few apps that do use the initial scanfile tree, but do
> not use any of the dvb-apps.
>
> (tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)

Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats.


>>
>>
>>> Meanwhile, your argument is for developers.  Developers can handle
>>> pulling from a separated tree for data files who shouldn't be clouding
>>> the history of source code development, anyway.  Developers are indeed
>>> used to dealing with multiple repositories, and if any developer
>>> isn't, then now is the time to get with the program!
>>
>>
>> It isn't that way. Users have to deal with 2 repositories as well.
>> Anyway,
>> the repository is not having that many developers to state that
>> developers
>> can handle all the burden. It is just but the reverse.
> Well one of the biggest issues was, that the scanfiles where ill
> maintained and projects where working around those shortcommings.
>
> The scanfiles are technically unrelated. They are data files, facts and
> can very logically live seperated :) Having commit messages pure for
> data files in a source tree just looks off.


The configuration files/data for dvb-apps.

>
> They simply have become a seperate entity as people (not developers)
> depend on them. (Yes there is wscan of course).
>
> Also, purely out of curiousity, how are the scanfiles used during
> development?

The scanfiles what you call them are the configuration files for dvb-apps,
rather than purely data files.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 01/10/2013 09:25 PM, Manu Abraham wrote:
>> Also, purely out of curiousity, how are the scanfiles used during
>> development?
> 
> The scanfiles what you call them are the configuration files for dvb-apps,
> rather than purely data files.

But you cannot change their format, so what's the point? You can use
them from a different directory or system ones...

-- 
js

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 01/10/2013 09:25 PM, Manu Abraham wrote:
>>> Also, purely out of curiousity, how are the scanfiles used during
>>> development?
>>
>> The scanfiles what you call them are the configuration files for
>> dvb-apps,
>> rather than purely data files.
>
> But you cannot change their format, so what's the point? You can use
> them from a different directory or system ones...

The format can be definitely changed. There's no issue to it.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 01/10/2013 09:38 PM, Manu Abraham wrote:
> The format can be definitely changed. There's no issue to it.

No you cannot. Applications depend on that, it's part of the dvb ABI. If
you changed that, you would do the same mistake as Mauro let it flowing
through his tree and it was pointed out by Linus in the link you sent...

-- 
js

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 01/10/2013 09:41 PM, Jiri Slaby wrote:
> On 01/10/2013 09:38 PM, Manu Abraham wrote:
>> The format can be definitely changed. There's no issue to it.
> 
> No you cannot. Applications depend on that, it's part of the dvb ABI. If
> you changed that, you would do the same mistake as Mauro let it flowing
> through his tree and it was pointed out by Linus in the link you sent...

Id you provide an abstraction library, convert all applications to use
that instead of the files, you can change them then. Not any time before.

-- 
js

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 01/10/13 21:42, Jiri Slaby wrote:
> On 01/10/2013 09:41 PM, Jiri Slaby wrote:
>> On 01/10/2013 09:38 PM, Manu Abraham wrote:
>>> The format can be definitely changed. There's no issue to it.
>>
>> No you cannot. Applications depend on that, it's part of the dvb ABI. If
>> you changed that, you would do the same mistake as Mauro let it flowing
>> through his tree and it was pointed out by Linus in the link you sent...
>
> Id you provide an abstraction library, convert all applications to use
> that instead of the files, you can change them then. Not any time before.
>

Well isn't the scan tables list a database of sorts? It contains the 
transponder settings for all public accessible transponders. Or should 
anyway.

The format, for now, suffices I'd think. Also, you already convert it 
sort of. You use dvbscan or whatever scan, to take those files and 
create channels.conf or what not from it (and search for extra 
transponders, but having _all_ transponders in the repository would be 
overkill though I think we do that for dvb-T?

So in a sense, it exists as that already :)

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 01/10/2013 09:38 PM, Manu Abraham wrote:
>> The format can be definitely changed. There's no issue to it.
>
> No you cannot. Applications depend on that, it's part of the dvb ABI. If
> you changed that, you would do the same mistake as Mauro let it flowing
> through his tree and it was pointed out by Linus in the link you sent...

I understand what you are thinking, but that's not exactly about it. The format
can simply be updated by adding newer params to it's end, thus not breaking
any of the applications.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 01/10/2013 09:49 PM, Manu Abraham wrote:
> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>> On 01/10/2013 09:38 PM, Manu Abraham wrote:
>>> The format can be definitely changed. There's no issue to it.
>>
>> No you cannot. Applications depend on that, it's part of the dvb ABI. If
>> you changed that, you would do the same mistake as Mauro let it flowing
>> through his tree and it was pointed out by Linus in the link you sent...
> 
> I understand what you are thinking, but that's not exactly about it. The format
> can simply be updated by adding newer params to it's end, thus not breaking
> any of the applications.

OK, but that still does not explain why it is requisite to have the data
along with the sources. There is no problem in updating both the files
and scandata separately, because it has to be compatible.

Also I'm not sure whether adding a column at the end wouldn't break the
apps.

-- 
js

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 01/10/2013 09:49 PM, Manu Abraham wrote:
>> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>>> On 01/10/2013 09:38 PM, Manu Abraham wrote:
>>>> The format can be definitely changed. There's no issue to it.
>>>
>>> No you cannot. Applications depend on that, it's part of the dvb ABI. If
>>> you changed that, you would do the same mistake as Mauro let it flowing
>>> through his tree and it was pointed out by Linus in the link you sent...
>>
>> I understand what you are thinking, but that's not exactly about it. The
>> format
>> can simply be updated by adding newer params to it's end, thus not
>> breaking
>> any of the applications.
>
> OK, but that still does not explain why it is requisite to have the data
> along with the sources. There is no problem in updating both the files
> and scandata separately, because it has to be compatible.
>

scenario1:

clone tree 1
make changes
update tree 1

scenario2:

clone tree 1
make changes
update tree 1

clone tree 2
make changes
update tree 2

It seems to me that scenario 2 is twice the work, to keep it updated. :-)
Simply no reason to do double the work.


> Also I'm not sure whether adding a column at the end wouldn't break the
> apps.


Don't worry. We have already done that in the past.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 01/10/13 21:41, Jiri Slaby wrote:
> On 01/10/2013 09:38 PM, Manu Abraham wrote:
>> The format can be definitely changed. There's no issue to it.
>
> No you cannot. Applications depend on that, it's part of the dvb ABI. If
> you changed that, you would do the same mistake as Mauro let it flowing
> through his tree and it was pointed out by Linus in the link you sent...
>

Actually, there's plenty of apps etc that depend on it. I know some 
distro's install it into /usr/share/dvb for all to use. I think actually 
only a very small handfull use their own scanfiles. Very small handfull 
I belive ;)

Re: [RFC] Initial scan files troubles and brainstorming

[Jonathan McCrohan]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Thu, 10 Jan 2013 21:55:28 +0100, Oliver Schinagl wrote:
> Actually, there's plenty of apps etc that depend on it. I know some 
> distro's install it into /usr/share/dvb for all to use. I think actually 
> only a very small handfull use their own scanfiles. Very small handfull 
> I belive ;)

Indeed. I have just gone to file an Intent To Package bug for the
dtv-scan-tables package in Debian, but I noticed that the COPYING and
README files were not split out from the dvb-apps tree.

Logically it would follow that dtv-scan-tables is also licenced under
LGPL, the same as dvb-apps, but this needs to be stated explicitly.
This is especially true for distributions which be redistributing
dtv-scan-tables.

Thanks,
Jon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Legallity of dtv-scan-tables Was: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 11-01-13 02:12, Jonathan McCrohan wrote:
> On Thu, 10 Jan 2013 21:55:28 +0100, Oliver Schinagl wrote:
>> Actually, there's plenty of apps etc that depend on it. I know some
>> distro's install it into /usr/share/dvb for all to use. I think actually
>> only a very small handfull use their own scanfiles. Very small handfull
>> I belive ;)
> Indeed. I have just gone to file an Intent To Package bug for the
> dtv-scan-tables package in Debian, but I noticed that the COPYING and
> README files were not split out from the dvb-apps tree.
If some have any pointers in what would be logical in the readme, i'll 
whip one up this afternoon.

but copying is an interesting point.
>
> Logically it would follow that dtv-scan-tables is also licenced under
> LGPL, the same as dvb-apps, but this needs to be stated explicitly.
> This is especially true for distributions which be redistributing
> dtv-scan-tables.
I don't think it is that logical actually. Remember the ntpd fiasco a 
few months back? Where some company claimed they had copyright on 
factual data?

This is as far as I can tell, factual data. A Satellite or Antenna is 
configured to broadcast in a certain way, the scan tables are a 
collection of this data. They get to us from volunteers who either scan 
for them or find 'official' docs from the broadcaster and re-arrange it 
to something useful to us.....

So who owns this data? Can it be licensed as GPL? Falls it under the 
Public Domain by default?

Personally, I think that the copyright license applied to the actual 
source code, but not the scan tables.

>
> Thanks,
> Jon
Oliver

Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Em Fri, 11 Jan 2013 01:12:33 +0000
Jonathan McCrohan <jmccrohan@gmail.com> escreveu:

> On Thu, 10 Jan 2013 21:55:28 +0100, Oliver Schinagl wrote:
> > Actually, there's plenty of apps etc that depend on it. I know some 
> > distro's install it into /usr/share/dvb for all to use. I think actually 
> > only a very small handfull use their own scanfiles. Very small handfull 
> > I belive ;)
> 
> Indeed. I have just gone to file an Intent To Package bug for the
> dtv-scan-tables package in Debian, but I noticed that the COPYING and
> README files were not split out from the dvb-apps tree.
> 
> Logically it would follow that dtv-scan-tables is also licenced under
> LGPL, the same as dvb-apps, but this needs to be stated explicitly.
> This is especially true for distributions which be redistributing
> dtv-scan-tables.

As this is currently a copy of the dvb-apps, and the other patches added
there are sent meant to be merged at dvb-apps, the license that applies
on it should be inherited.

That's said, this is just database entries where the values were obtained
from a public service. Anyone else with access to the same
transponders/carriers would be obtaining the very same data. So, I don't 
think that copyright law applies here. IANAL, but it sounds to me
that such info would be public domain.

Yet, to avoid legal issues, I suggest to copy the COPYING from
the dvb-apps tree. Also, sooner or later a Makefile will likely be added
there, and maybe some ancillary scripts. So, it makes sense to state
the license there anyway.

Regards,
Mauro

Re: [RFC] Initial scan files troubles and brainstorming

[Benny Amorsen]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> That's said, this is just database entries where the values were obtained
> from a public service. Anyone else with access to the same
> transponders/carriers would be obtaining the very same data. So, I don't 
> think that copyright law applies here. IANAL, but it sounds to me
> that such info would be public domain.

Please be aware that in at least the EU database compilations _can_ be
copyrighted. It makes life a lot simpler for distributions if you just
pretend that it can be copyrighted and apply a license. If you want
something approaching public domain, the BSD license is an obvious
choice. Going with the LGPL as you propose later in the email is
perfectly fine too.


/Benny

Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Em Fri, 11 Jan 2013 15:10:38 +0100
Benny Amorsen <benny+usenet@amorsen.dk> escreveu:

> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
> > That's said, this is just database entries where the values were obtained
> > from a public service. Anyone else with access to the same
> > transponders/carriers would be obtaining the very same data. So, I don't 
> > think that copyright law applies here. IANAL, but it sounds to me
> > that such info would be public domain.
> 
> Please be aware that in at least the EU database compilations _can_ be
> copyrighted. It makes life a lot simpler for distributions if you just
> pretend that it can be copyrighted and apply a license. 

Yes. Better safe than sorry.

> If you want
> something approaching public domain, the BSD license is an obvious
> choice. Going with the LGPL as you propose later in the email is
> perfectly fine too.

Changing to BSD could be a problem, as re-licensing would require an
ack from the original contributors, except if the license is a compatible
one. Collecting everyone's ack on such change could be painful, and for
no good reason.

So, to make it simpler, I would just use the LGPL.

Regards,
Mauro

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 11-01-13 13:23, Mauro Carvalho Chehab wrote:
> Em Fri, 11 Jan 2013 01:12:33 +0000
> Jonathan McCrohan <jmccrohan@gmail.com> escreveu:
>
>> On Thu, 10 Jan 2013 21:55:28 +0100, Oliver Schinagl wrote:
>>> Actually, there's plenty of apps etc that depend on it. I know some
>>> distro's install it into /usr/share/dvb for all to use. I think actually
>>> only a very small handfull use their own scanfiles. Very small handfull
>>> I belive ;)
>> Indeed. I have just gone to file an Intent To Package bug for the
>> dtv-scan-tables package in Debian, but I noticed that the COPYING and
>> README files were not split out from the dvb-apps tree.
>>
>> Logically it would follow that dtv-scan-tables is also licenced under
>> LGPL, the same as dvb-apps, but this needs to be stated explicitly.
>> This is especially true for distributions which be redistributing
>> dtv-scan-tables.
> As this is currently a copy of the dvb-apps, and the other patches added
> there are sent meant to be merged at dvb-apps, the license that applies
> on it should be inherited.
>
> That's said, this is just database entries where the values were obtained
> from a public service. Anyone else with access to the same
> transponders/carriers would be obtaining the very same data. So, I don't
> think that copyright law applies here. IANAL, but it sounds to me
> that such info would be public domain.
>
> Yet, to avoid legal issues, I suggest to copy the COPYING from
> the dvb-apps tree. Also, sooner or later a Makefile will likely be added
> there, and maybe some ancillary scripts. So, it makes sense to state
> the license there anyway.
License has been merged from dvb-apps (keeping history) and pushed to 
the repo.

> Regards,
> Mauro

Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Em Fri, 11 Jan 2013 01:55:34 +0530
Manu Abraham <abraham.manu@gmail.com> escreveu:

> On 1/11/13, Oliver Schinagl <oliver+list@schinagl.nl> wrote:
> >> they can say anything what they want, which makes no sense at all.
> > Well there are a few apps that do use the initial scanfile tree, but do
> > not use any of the dvb-apps.
> >
> > (tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)
> 
> Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats.

Both mplayer and vlc work with the channels-conf files.

Cheers,
Mauro

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em Fri, 11 Jan 2013 01:55:34 +0530
> Manu Abraham <abraham.manu@gmail.com> escreveu:
>
>> On 1/11/13, Oliver Schinagl <oliver+list@schinagl.nl> wrote:
>> >> they can say anything what they want, which makes no sense at all.
>> > Well there are a few apps that do use the initial scanfile tree, but do
>> > not use any of the dvb-apps.
>> >
>> > (tvheadend, kaffeine appearantly, i'm guessing VDR and MythTV aswell?)
>>
>> Only tvheadend and kaffeine AFAIK. VDR and MythTV have their own formats.
>
> Both mplayer and vlc work with the channels-conf files.

True. they depend upon the output from dvbscan. So when scan changes format,
they will also need to "update formats to acquire new functionality", else they
will be stuck with old functionality.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Oliver Schinagl <oliver+list@schinagl.nl> wrote:
> On 01/10/13 20:04, Manu Abraham wrote:
>> It isn't that way. Users have to deal with 2 repositories as well.
>> Anyway,
>> the repository is not having that many developers to state that
>> developers
>> can handle all the burden. It is just but the reverse.
> Well one of the biggest issues was, that the scanfiles where ill
> maintained and projects where working around those shortcommings.

I do see that Christoph hasn't been around lately. I would appreciate
it as well, if you would maintain the files within the dvb-apps repository
itself.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 01/10/2013 07:46 PM, Manu Abraham wrote:
> The scan files and config files are very specific to dvb-apps, some
> applications
> do rely on these config files. It doesn't really make sense to have
> split out config
> files for these  small applications.

I don't care where they are, really. However I'm strongly against
duplicating them. Feel free to remove the newly created repository, I'll
be fine with that.

> So according to you, you want to make it
> still harder for someone to work with dvb-apps.

I wasn't the one to suggest a separate directory for the data, there is
no point in blaming me...

-- 
js

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 01/10/2013 07:46 PM, Manu Abraham wrote:
>> The scan files and config files are very specific to dvb-apps, some
>> applications
>> do rely on these config files. It doesn't really make sense to have
>> split out config
>> files for these  small applications.
>
> I don't care where they are, really. However I'm strongly against
> duplicating them. Feel free to remove the newly created repository, I'll
> be fine with that.

I haven't duplicated anything at all. It is Mauro who has duplicated stuff,
by creating a new tree altogether.

if you need the scan files to be properly maintained then you need to
handle it in the same repository altogether. Not by separating out the
configuration files of a few applications.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 01/10/2013 08:08 PM, Manu Abraham wrote:
> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>> On 01/10/2013 07:46 PM, Manu Abraham wrote:
>>> The scan files and config files are very specific to dvb-apps, some
>>> applications
>>> do rely on these config files. It doesn't really make sense to have
>>> split out config
>>> files for these  small applications.
>>
>> I don't care where they are, really. However I'm strongly against
>> duplicating them. Feel free to remove the newly created repository, I'll
>> be fine with that.
> 
> I haven't duplicated anything at all. It is Mauro who has duplicated stuff,
> by creating a new tree altogether.

I didn't accuse you. This was a general comment to everybody. Whatever
the consensus is at the end, do not duplicate the data.

> if you need the scan files to be properly maintained then you need to
> handle it in the same repository altogether. Not by separating out the
> configuration files of a few applications.

That's up to you guys to decide. I don't mind either option.

-- 
js

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 01/10/2013 08:08 PM, Manu Abraham wrote:
>> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>>> On 01/10/2013 07:46 PM, Manu Abraham wrote:
>>>> The scan files and config files are very specific to dvb-apps, some
>>>> applications
>>>> do rely on these config files. It doesn't really make sense to have
>>>> split out config
>>>> files for these  small applications.
>>>
>>> I don't care where they are, really. However I'm strongly against
>>> duplicating them. Feel free to remove the newly created repository, I'll
>>> be fine with that.
>>
>> I haven't duplicated anything at all. It is Mauro who has duplicated
>> stuff,
>> by creating a new tree altogether.
>
> I didn't accuse you. This was a general comment to everybody. Whatever
> the consensus is at the end, do not duplicate the data.

Eventually what will happen is that, as applications do get developed,
the config files which are alongwith the applications will have proper
compatibility with the applications while, the split out config files will
be in a different state, providing nothing but pain for everyone.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Em Fri, 11 Jan 2013 00:38:18 +0530
Manu Abraham <abraham.manu@gmail.com> escreveu:

> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
> > On 01/10/2013 07:46 PM, Manu Abraham wrote:
> >> The scan files and config files are very specific to dvb-apps, some
> >> applications
> >> do rely on these config files. It doesn't really make sense to have
> >> split out config
> >> files for these  small applications.
> >
> > I don't care where they are, really. However I'm strongly against
> > duplicating them. Feel free to remove the newly created repository, I'll
> > be fine with that.
> 
> I haven't duplicated anything at all. It is Mauro who has duplicated stuff,
> by creating a new tree altogether.

I only did it by request, and after having some consensus at the ML, and
after people explicitly asking me to do that.

I even tried to not express my opinion to anybody. But it seems I'm
forced by you to give it. So, let it be.

The last patches from you there were 11 months ago, and didn't bring any
new functionality there... they are just indentation fixes:
	http://www.linuxtv.org/hg/dvb-apps/

The last one with a new functionality seems to be this one, 15 months ago:
	http://www.linuxtv.org/hg/dvb-apps/rev/d4e8bf5658ce

Also, people find a very bad time when they submit any fixes for the driver
you wrote, as you doesn't seem to have enough time to review their patches.

So, I suspect that you're a very very busy person, with almost no time to
maintain your previous work. If something has changed, and you're now
finding more time, I'd pleased if you could review the patches that 
are there for a long time (there is one from 2011 that it is a rebase of
an even older patch) before re-doing Oliver's scanfile updates at dvb-tools:
	http://www.spinics.net/lists/linux-media/msg58283.html

Considering that nobody is having much time for the dvb-apps tree
nowadays, I really think that it would be great to get someone
with more time to maintain those files, as otherwise the update scan
files may be on the limbo for a long time, and releasing us to have
more time with development.

As proposed by Oliver, it seemed to be a good idea to have it on a
separate tree, as those scan files are actually independent of the 
dvb-apps, and can be used by other applications.

That's why I welcomed Oliver's initiative to maintain it, and I wish
him a good work with that.

> Eventually what will happen is that, as applications do get developed,
> the config files which are alongwith the applications will have proper
> compatibility with the applications while, the split out config files will
> be in a different state, providing nothing but pain for everyone.

The format of those files can't be changed without breaking other existing
applications that relies on its format, like mplayer, vlc, etc.

It could make sense, though, to convert them in the future to a more generic
format that would be delivery-system independent and that could easily be
converted into all application-specific formats, and add there some
format-change tool that would dynamically generate the files at 
vdr, dvb-apps, kaffeine... format.

By having it on a separate tree, with its own maintainer, Oliver can
focus on it, without needing to be bothered with maintaining the dvb-apps.

So, it makes all sense for me to have it maintained in separate.

That's said, there's no problem on having those files maintained on two
or more trees. Actually, there are already dozens of forks of it, as each
distribution has its own dvb-apps fork, some outdated and eventually some
with their own scan files there.

So, if no agreement is reached, I would just keep it as is for a while and
review it maybe an year later.

Regards,
Mauro

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em Fri, 11 Jan 2013 00:38:18 +0530
> Manu Abraham <abraham.manu@gmail.com> escreveu:
>
>> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>> > On 01/10/2013 07:46 PM, Manu Abraham wrote:
>> >> The scan files and config files are very specific to dvb-apps, some
>> >> applications
>> >> do rely on these config files. It doesn't really make sense to have
>> >> split out config
>> >> files for these  small applications.
>> >
>> > I don't care where they are, really. However I'm strongly against
>> > duplicating them. Feel free to remove the newly created repository,
>> > I'll
>> > be fine with that.
>>
>> I haven't duplicated anything at all. It is Mauro who has duplicated
>> stuff,
>> by creating a new tree altogether.
>
> I only did it by request, and after having some consensus at the ML, and
> after people explicitly asking me to do that.
>

Having consensus implies that the people involved with it are in that loop,
rather than having a superfluous one with no one of it in that loop.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em Fri, 11 Jan 2013 00:38:18 +0530
> Manu Abraham <abraham.manu@gmail.com> escreveu:
>
>> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>> > On 01/10/2013 07:46 PM, Manu Abraham wrote:
>> >> The scan files and config files are very specific to dvb-apps, some
>> >> applications
>> >> do rely on these config files. It doesn't really make sense to have
>> >> split out config
>> >> files for these  small applications.
>> >
>> > I don't care where they are, really. However I'm strongly against
>> > duplicating them. Feel free to remove the newly created repository,
>> > I'll
>> > be fine with that.
>>
>> I haven't duplicated anything at all. It is Mauro who has duplicated
>> stuff,
>> by creating a new tree altogether.
>
> I only did it by request, and after having some consensus at the ML, and
> after people explicitly asking me to do that.
>
> I even tried to not express my opinion to anybody. But it seems I'm
> forced by you to give it. So, let it be.
>
> The last patches from you there were 11 months ago, and didn't bring any
> new functionality there... they are just indentation fixes:
> 	http://www.linuxtv.org/hg/dvb-apps/


The way you do things, it all ends up like this.

https://lkml.org/lkml/2012/12/23/75


Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 01/10/13 21:32, Manu Abraham wrote:
> On 1/11/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>> Em Fri, 11 Jan 2013 00:38:18 +0530
>> Manu Abraham <abraham.manu@gmail.com> escreveu:
>>
>>> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>>>> On 01/10/2013 07:46 PM, Manu Abraham wrote:
>>>>> The scan files and config files are very specific to dvb-apps, some
>>>>> applications
>>>>> do rely on these config files. It doesn't really make sense to have
>>>>> split out config
>>>>> files for these  small applications.
>>>>
>>>> I don't care where they are, really. However I'm strongly against
>>>> duplicating them. Feel free to remove the newly created repository,
>>>> I'll
>>>> be fine with that.
>>>
>>> I haven't duplicated anything at all. It is Mauro who has duplicated
>>> stuff,
>>> by creating a new tree altogether.
>>
>> I only did it by request, and after having some consensus at the ML, and
>> after people explicitly asking me to do that.
>>
>> I even tried to not express my opinion to anybody. But it seems I'm
>> forced by you to give it. So, let it be.
>>
>> The last patches from you there were 11 months ago, and didn't bring any
>> new functionality there... they are just indentation fixes:
>> 	http://www.linuxtv.org/hg/dvb-apps/
>
>
> The way you do things, it all ends up like this.
>
> https://lkml.org/lkml/2012/12/23/75
That's just mean and below the belt.

Anyway, I've brought this issue up on the 18th of oktober 2012 on this 
mailing list. I had zero replies until early december. Jonathan 
commented a little and said it was a good idea.

Also a few comments about how their patches to scanfiles (data files, 
facts) where ignored for weeks to an end.

Mauro didn't get involved to have everybody that is a maintainer etc get 
a good chance to respond.

The only thing that came from this, is that someone actually stopped 
maintaining it.

Then after everything actually was done (for the better imo), you come 
in and say it's a bad thing, but dont' really tell us why. Other than it 
makes development hard for you, which nobody really agree's to with.


Anyway, fighting about it won't help anyone, but a good argument as to 
which procedure is better is good for everyone :)

Oliver

>
>
> Manu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On 1/11/13, Oliver Schinagl <oliver+list@schinagl.nl> wrote:
> On 01/10/13 21:32, Manu Abraham wrote:
>> On 1/11/13, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>>> Em Fri, 11 Jan 2013 00:38:18 +0530
>>> Manu Abraham <abraham.manu@gmail.com> escreveu:
>>>
>>>> On 1/11/13, Jiri Slaby <jirislaby@gmail.com> wrote:
>>>>> On 01/10/2013 07:46 PM, Manu Abraham wrote:
>>>>>> The scan files and config files are very specific to dvb-apps, some
>>>>>> applications
>>>>>> do rely on these config files. It doesn't really make sense to have
>>>>>> split out config
>>>>>> files for these  small applications.
>>>>>
>>>>> I don't care where they are, really. However I'm strongly against
>>>>> duplicating them. Feel free to remove the newly created repository,
>>>>> I'll
>>>>> be fine with that.
>>>>
>>>> I haven't duplicated anything at all. It is Mauro who has duplicated
>>>> stuff,
>>>> by creating a new tree altogether.
>>>
>>> I only did it by request, and after having some consensus at the ML, and
>>> after people explicitly asking me to do that.
>>>
>>> I even tried to not express my opinion to anybody. But it seems I'm
>>> forced by you to give it. So, let it be.
>>>
>>> The last patches from you there were 11 months ago, and didn't bring any
>>> new functionality there... they are just indentation fixes:
>>> 	http://www.linuxtv.org/hg/dvb-apps/
>>
>>
>> The way you do things, it all ends up like this.
>>
>> https://lkml.org/lkml/2012/12/23/75
> That's just mean and below the belt.
>
> Anyway, I've brought this issue up on the 18th of oktober 2012 on this
> mailing list. I had zero replies until early december. Jonathan
> commented a little and said it was a good idea.
>
> Also a few comments about how their patches to scanfiles (data files,
> facts) where ignored for weeks to an end.
>


There was someone who was actively maintaining the config files.
One cannot simply state something different unless that person has to say
something. In this case as soon as Christoph talked about his stand,
I did express my opinion as well.



> Mauro didn't get involved to have everybody that is a maintainer etc get
> a good chance to respond.
>

Mauro doesn't do anything wrt dvb-apps. I don't understand, what you
are trying to state here.


> The only thing that came from this, is that someone actually stopped
> maintaining it.
>
> Then after everything actually was done (for the better imo), you come
> in and say it's a bad thing, but dont' really tell us why. Other than it
> makes development hard for you, which nobody really agree's to with.

At least you should have the courtesy to talk about it with the people
who are/were working with it, rather than the people who have no
connection to it.

I don't want to let go of the efforts that you would like to put into, and
hence stated that it would be appreciated if you would maintain the
config files within the dvb-apps tree.

Just like how you think it is bad for the applications to carry it's own
configuration files, I think that it is better for any application to carry
it's own configuration files.

Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Em Thu, 10 Jan 2013 21:51:29 +0100
Oliver Schinagl <oliver+list@schinagl.nl> escreveu:

> Anyway, fighting about it won't help anyone

Agreed. From my side, don't expect further comments. That's hopefully
my last email on this thread.

Oliver,

You owns your time. So, it is really your call.

>From my side, I appreciate your efforts on keep maintaining it. 

I don't really care if this is done as a separate tree and/or together 
with dvb-apps, although, except for the scan files, the dvb-apps seem 
pretty much orphaned for a long time. So, among other reasons, IMHO
it is better to keep it forked.

In any case, reimporting the files from an external tree is easy. It is
equally easy to add a script at dvb-apps and on other applications that
would take a tarball of it and copy the files there. We do that approach
on v4l-utils, in order to sync it with kernel headers and kernel IR scancode
tables, as we do need new headers there during development, and users do
need the very latest IR scancode tables.

If you decide to keep it in separate, I recommend you to add there some
version schema to make easier for distributions that may want to add
a package there, for them to track when this gets updated.

Also, just like what we do with media-build's "todaytar" target, it may 
also make some sense to have an script running at linuxtv.org that would
create daily tarballs when a new commit is merged there, or when a new tag
is added. That would help to have scripts at applications to sync with
the latest files.

If you decide to either drop the tree or to add such tarball script
at the server, please ping me.

-- 

Cheers,
Mauro

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 01/10/13 23:11, Mauro Carvalho Chehab wrote:
> Em Thu, 10 Jan 2013 21:51:29 +0100
> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>
>> Anyway, fighting about it won't help anyone
>
> Agreed. From my side, don't expect further comments. That's hopefully
> my last email on this thread.
>
> Oliver,
>
> You owns your time. So, it is really your call.
Well I did write the initial plea for the seperation. :)

>
>  From my side, I appreciate your efforts on keep maintaining it.
I will do my very best for as long as time permits. I find it personally 
important that my scanfiles are updated as quickly as possibly and so 
will also update others as quickly as I can.

>
> I don't really care if this is done as a separate tree and/or together
> with dvb-apps, although, except for the scan files, the dvb-apps seem
> pretty much orphaned for a long time. So, among other reasons, IMHO
> it is better to keep it forked.
I still think it does make sense for reasons I posted 3 months ago.
>
> In any case, reimporting the files from an external tree is easy. It is
> equally easy to add a script at dvb-apps and on other applications that
> would take a tarball of it and copy the files there. We do that approach
> on v4l-utils, in order to sync it with kernel headers and kernel IR scancode
> tables, as we do need new headers there during development, and users do
> need the very latest IR scancode tables.
If dvb-apps depends on the scanfiles that horribly specifically, then a 
script to copy over the latest release would be best.

>
> If you decide to keep it in separate, I recommend you to add there some
> version schema to make easier for distributions that may want to add
> a package there, for them to track when this gets updated.
Personally, I'd say date based would be best. After each commit a new 
tarball should be created. Since it's not 'code' that changes, but 
factual data, any change warrants a release. So 
dtv-scan-files-2013011.tar.bz2/xz and is common?

if for any reason a second release is needed on the same date ... too 
bad :p it's extremly unlikly anyway and can be done the next day's date. 
Or add an index after the date.

>
> Also, just like what we do with media-build's "todaytar" target, it may
> also make some sense to have an script running at linuxtv.org that would
> create daily tarballs when a new commit is merged there, or when a new tag
> is added. That would help to have scripts at applications to sync with
> the latest files.
Well you want to release every commit really, as above stated a commit 
indicates a change in a transponder. Users of that transponder want to 
be able to use it asap.

>
> If you decide to either drop the tree or to add such tarball script
> at the server, please ping me.
Ping :p
>

Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Em Thu, 10 Jan 2013 23:57:42 +0100
Oliver Schinagl <oliver+list@schinagl.nl> escreveu:

> On 01/10/13 23:11, Mauro Carvalho Chehab wrote:
> > Em Thu, 10 Jan 2013 21:51:29 +0100
> > Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
> >
> >> Anyway, fighting about it won't help anyone
> >
> > Agreed. From my side, don't expect further comments. That's hopefully
> > my last email on this thread.
> >
> > Oliver,
> >
> > You owns your time. So, it is really your call.
> Well I did write the initial plea for the seperation. :)
> 
> >
> >  From my side, I appreciate your efforts on keep maintaining it.
> I will do my very best for as long as time permits. I find it personally 
> important that my scanfiles are updated as quickly as possibly and so 
> will also update others as quickly as I can.
> 
> >
> > I don't really care if this is done as a separate tree and/or together
> > with dvb-apps, although, except for the scan files, the dvb-apps seem
> > pretty much orphaned for a long time. So, among other reasons, IMHO
> > it is better to keep it forked.
> I still think it does make sense for reasons I posted 3 months ago.
> >
> > In any case, reimporting the files from an external tree is easy. It is
> > equally easy to add a script at dvb-apps and on other applications that
> > would take a tarball of it and copy the files there. We do that approach
> > on v4l-utils, in order to sync it with kernel headers and kernel IR scancode
> > tables, as we do need new headers there during development, and users do
> > need the very latest IR scancode tables.
> If dvb-apps depends on the scanfiles that horribly specifically, then a 
> script to copy over the latest release would be best.
> 
> >
> > If you decide to keep it in separate, I recommend you to add there some
> > version schema to make easier for distributions that may want to add
> > a package there, for them to track when this gets updated.
> Personally, I'd say date based would be best. After each commit a new 
> tarball should be created. Since it's not 'code' that changes, but 
> factual data, any change warrants a release. So 
> dtv-scan-files-2013011.tar.bz2/xz and is common?
> 
> if for any reason a second release is needed on the same date ... too 
> bad :p it's extremly unlikly anyway and can be done the next day's date. 
> Or add an index after the date.

To re-use the existing script, you'll need to create a Makefile target
to generate such tar. The script runs once during the night, comparing the
previous commit hash with the current one. If different, it creates a new
tarball.

The Makefile there could be as simple as:

tgz:
	git archive --format tgz HEAD >dtv-scan-files-`date +"%Y%m%d.%H:%M"`.tar.gz

The above is for tar.gz - I don't object if you want to use a different
compression provided that there are just one format. You may need to play
a little bit with git config files, to add support for xz and bz2.

> >
> > Also, just like what we do with media-build's "todaytar" target, it may
> > also make some sense to have an script running at linuxtv.org that would
> > create daily tarballs when a new commit is merged there, or when a new tag
> > is added. That would help to have scripts at applications to sync with
> > the latest files.
> Well you want to release every commit really, as above stated a commit 
> indicates a change in a transponder. Users of that transponder want to 
> be able to use it asap.
> 
> >
> > If you decide to either drop the tree or to add such tarball script
> > at the server, please ping me.
> Ping :p
> >

Please add a Makefile there and ping me, and I'll adapt the existing script
to also run on this project.

-- 

Cheers,
Mauro

Re: [RFC] Initial scan files troubles and brainstorming

[Jiri Slaby]

On 01/11/2013 01:39 PM, Mauro Carvalho Chehab wrote:
> tgz:
> 	git archive --format tgz HEAD >dtv-scan-files-`date +"%Y%m%d.%H:%M"`.tar.gz

Better to use the top commit date:
git log -n1 --date=short --pretty=format:%ad

You won't generate a snapshot every day with the same contents then.

or %ad-g%p if you want also a short commit id in there.

-- 
js

daily tarballs of dtv-scan-tables - was Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Hi Oliver,

Em Fri, 11 Jan 2013 10:39:37 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> Em Thu, 10 Jan 2013 23:57:42 +0100
> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
> 
...
> > Personally, I'd say date based would be best. After each commit a new 
> > tarball should be created. Since it's not 'code' that changes, but 
> > factual data, any change warrants a release. So 
> > dtv-scan-files-2013011.tar.bz2/xz and is common?
> > 
> > if for any reason a second release is needed on the same date ... too 
> > bad :p it's extremly unlikly anyway and can be done the next day's date. 
> > Or add an index after the date.
> 
> To re-use the existing script, you'll need to create a Makefile target
> to generate such tar. The script runs once during the night, comparing the
> previous commit hash with the current one. If different, it creates a new
> tarball.
> 
> The Makefile there could be as simple as:
> 
> tgz:
> 	git archive --format tgz HEAD >dtv-scan-files-`date +"%Y%m%d.%H:%M"`.tar.gz
> 
> The above is for tar.gz - I don't object if you want to use a different
> compression provided that there are just one format. You may need to play
> a little bit with git config files, to add support for xz and bz2.

I found some time today to implement a script to generate the tarball 
files for dtv-scan-tables at the LinuxTV server.

The script runs daily, checking if there was any new changeset at the
repository. If it finds a new changeset there, it will take the date
and the changeset of the latest commit at the tree and them as part of
the tarball name, adding them to the following directory:

	http://linuxtv.org/downloads/dtv-scan-tables/

The script will also create an hyperlink of the latest tarball at:
	dtv-scan-tables-LATEST.tar.bz2

Every time a new file is added there, it will also update the md5sum file,
that could be used by someone to check the downloads.

Regards,
Mauro

Re: daily tarballs of dtv-scan-tables - was Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 06/03/13 19:21, Mauro Carvalho Chehab wrote:
> Hi Oliver,
>
> Em Fri, 11 Jan 2013 10:39:37 -0200
> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
>
>> Em Thu, 10 Jan 2013 23:57:42 +0100
>> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>>
> ...
>>> Personally, I'd say date based would be best. After each commit a new
>>> tarball should be created. Since it's not 'code' that changes, but
>>> factual data, any change warrants a release. So
>>> dtv-scan-files-2013011.tar.bz2/xz and is common?
>>>
>>> if for any reason a second release is needed on the same date ... too
>>> bad :p it's extremly unlikly anyway and can be done the next day's date.
>>> Or add an index after the date.
>>
>> To re-use the existing script, you'll need to create a Makefile target
>> to generate such tar. The script runs once during the night, comparing the
>> previous commit hash with the current one. If different, it creates a new
>> tarball.
>>
>> The Makefile there could be as simple as:
>>
>> tgz:
>> 	git archive --format tgz HEAD >dtv-scan-files-`date +"%Y%m%d.%H:%M"`.tar.gz
>>
>> The above is for tar.gz - I don't object if you want to use a different
>> compression provided that there are just one format. You may need to play
>> a little bit with git config files, to add support for xz and bz2.
>
> I found some time today to implement a script to generate the tarball
> files for dtv-scan-tables at the LinuxTV server.
>
> The script runs daily, checking if there was any new changeset at the
> repository. If it finds a new changeset there, it will take the date
> and the changeset of the latest commit at the tree and them as part of
> the tarball name, adding them to the following directory:
>
> 	http://linuxtv.org/downloads/dtv-scan-tables/
>
> The script will also create an hyperlink of the latest tarball at:
> 	dtv-scan-tables-LATEST.tar.bz2
Is there any easy way for me to see the script? Just so I can learn from it.
>
> Every time a new file is added there, it will also update the md5sum file,
> that could be used by someone to check the downloads.
That is very cool and very much thank you.

I'll immediately publicly admit I have been slacking here. I should have 
picked up on that and done it. I've been dragged away and been busy with 
http://linux-sunxi.org.

Anyway Thank you for picking that up. The dtv tree should be up to date 
however, all messages I saw passing the mailing lists have been pushed.

I will (slowly) inform others that are interested (package maintainers) 
and see how it goes.

Thanks again Mauro!
>
> Regards,
> Mauro
>
Oliver

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

Mauro,

On 09-01-13 15:37, Mauro Carvalho Chehab wrote:
> Hi Oliver,
>
> Em Wed, 09 Jan 2013 13:24:13 +0100
> Oliver Schinagl <oliver@schinagl.nl> escreveu:
>
>>>>>> If I understood it right, you want to split the scan files into a separate
>>>>>> git tree and maintain it, right?
>>>>>>
>>>>>> I'm ok with that.
<snip>
>>>>> I also migrated the dvb-apps changesets with the tables to: 
>>>>> http://git.linuxtv.org/dtv-scan-tables.git Feel free to maintain it.
Thank you, this will be the new name for it (I will locally rename it) 
and try my bestest to maintain it :)

I will put a mention on the wiki 'how to submit scanfiles' (via the ML 
with tags in subject/pull requests) so people have a clear way how to 
submit them and I have a clear way to find them.

>
> You should also have access to the dvb-apps hg tree. IMHO, it makes sense
> to remove the files from there, and add a pointer there (README?) to the
> new tree.
I will remove the scanfiles from there, add/edit the readme that the 
tree is a dependancy?
>
> Regards,
> Mauro.
>
Oliver

Re: [RFC] Initial scan files troubles and brainstorming

[Mauro Carvalho Chehab]

Em Wed, 09 Jan 2013 15:44:30 +0100
Oliver Schinagl <oliver+list@schinagl.nl> escreveu:

> Mauro,
> 
> On 09-01-13 15:37, Mauro Carvalho Chehab wrote:
> > Hi Oliver,
> >
> > Em Wed, 09 Jan 2013 13:24:13 +0100
> > Oliver Schinagl <oliver@schinagl.nl> escreveu:
> >
> >>>>>> If I understood it right, you want to split the scan files into a separate
> >>>>>> git tree and maintain it, right?
> >>>>>>
> >>>>>> I'm ok with that.
> <snip>
> >>>>> I also migrated the dvb-apps changesets with the tables to: 
> >>>>> http://git.linuxtv.org/dtv-scan-tables.git Feel free to maintain it.
> Thank you, this will be the new name for it (I will locally rename it) 
> and try my bestest to maintain it :)
> 
> I will put a mention on the wiki 'how to submit scanfiles' (via the ML 
> with tags in subject/pull requests) so people have a clear way how to 
> submit them and I have a clear way to find them.

Great!

> >
> > You should also have access to the dvb-apps hg tree. IMHO, it makes sense
> > to remove the files from there, and add a pointer there (README?) to the
> > new tree.
> I will remove the scanfiles from there, add/edit the readme that the 
> tree is a dependancy?

Please do it. You'll likely need to also add there at the tree a Makefile
with an install target, in order to help distros to package it, and
remove the corresponding scan files install Makefile targets at dvb-apps.

-- 

Cheers,
Mauro

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 09-01-13 16:01, Mauro Carvalho Chehab wrote:
> Em Wed, 09 Jan 2013 15:44:30 +0100
> Oliver Schinagl <oliver+list@schinagl.nl> escreveu:
>
>> Mauro,
>>
>> On 09-01-13 15:37, Mauro Carvalho Chehab wrote:
>>> Hi Oliver,
>>>
>>> Em Wed, 09 Jan 2013 13:24:13 +0100
>>> Oliver Schinagl <oliver@schinagl.nl> escreveu:
>>>
>>>>>>>> If I understood it right, you want to split the scan files into a separate
>>>>>>>> git tree and maintain it, right?
>>>>>>>>
>>>>>>>> I'm ok with that.
>> <snip>
>>>>>>> I also migrated the dvb-apps changesets with the tables to:
>>>>>>> http://git.linuxtv.org/dtv-scan-tables.git Feel free to maintain it.
>> Thank you, this will be the new name for it (I will locally rename it)
>> and try my bestest to maintain it :)
>>
>> I will put a mention on the wiki 'how to submit scanfiles' (via the ML
>> with tags in subject/pull requests) so people have a clear way how to
>> submit them and I have a clear way to find them.
> Great!
>
>>> You should also have access to the dvb-apps hg tree. IMHO, it makes sense
>>> to remove the files from there, and add a pointer there (README?) to the
>>> new tree.
>> I will remove the scanfiles from there, add/edit the readme that the
>> tree is a dependancy?
> Please do it. You'll likely need to also add there at the tree a Makefile
> with an install target, in order to help distros to package it, and
> remove the corresponding scan files install Makefile targets at dvb-apps.
>
Will do as soon as I figure out how to gain access and and configure my 
local git install. I'm quite new to this multiple private key stuff and 
can't get it to work for now (i'll look into that for now). I feel 
stupid enough for asking :p

I'll first add my local patches and then see how i can 'fix' dvb-apps to 
remove the old stuff.

Re: [RFC] Initial scan files troubles and brainstorming

[Johannes Stezenbach]

On Wed, Jan 09, 2013 at 10:43:23AM +0100, Oliver Schinagl wrote:
> On 08-01-13 21:01, Johannes Stezenbach wrote:
> >On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
> >>On 07-01-13 11:46, Jiri Slaby wrote:
> >>>On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
> >>>>Unfortunatly, I have had zero replies.
> >>>Hmm, it's sad there is a silence in this thread from linux-media guys :/.
> >>In their defense, they are very very busy people ;) chatter on this
> >>thread does bring it up however.
> >This is such a nice thing to say :-)
> >But it might be that Mauro thinks the dvb-apps maintainer should
> >respond, but apparently there is no dvb-apps maintainer...
> >Maybe you should ask Mauro directly to create an account for you
> >to implement what you proposed.
> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
> decides what I suggested is a good idea? I personally obviously
> think it is ;) and even more so if dvb-apps are unmaintained.

Well, if you become the dvb-apps maintainer, then _you_ decide
if it's a good idea.  That's part of the defintion of "maintainer" :-)
It doesn't hurt to listen to users, but if no one comments
you can do whatever you want with it.

But I'm only acting as kind of a webmaster, Mauro creates the accounts.
So we have to wait for him to respond.

> I guess the question now becomes 'who okay's this change? Who says
> 'okay, lets do it this way. Once that is answered we can go from
> there ;)

I guess you could ask the maintainer of the dvb-apps package
of your favourite distribution for opinions, and also check
which other packages depend on dvb-apps.


Johannes

Re: [RFC] Initial scan files troubles and brainstorming

[Christoph Pfister]

Okay guys, I think this is a good time to discuss scan file
maintenance [ should have taken care of it earlier, but well ...].

I've been updating the scan data for the past few years, but found
barely no time in the last (many!) months. This won't change in
future, so I've decided to step down from the task; may others do what
is necessary ...

@Johannes: As I don't need the account anymore, please delete it.

Christoph


2013/1/7 Jiri Slaby <jirislaby@gmail.com>:
> On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
>> Unfortunatly, I have had zero replies.
>
> Hmm, it's sad there is a silence in this thread from linux-media guys :/.
>
>> So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us
>> with updated polish DVB-T frequencies for his region. This has yet to be
>> merged, almost 3 weeks later.
>
> I sent a patch for cz data too:
> https://patchwork.kernel.org/patch/1844201/
>
>> I'll quickly repeat why I think this approach would be quite reasonable.
>>
>> * dvb-apps binary changes don't result in unnecessary releases
>> * frequency updates don't result in unnecessary dvb-app releases
>> * Less strict requirements for commits (code reviews etc)
>
> Well the code should be reviewed still. See commit a2e96055db297 in your
> repo, it's bogus. The freq added is in kHz instead of MHz.
>
>> * Possibly easier entry for new submitters
>> * much easier to package (tag it once per month if an update was)
>> * Separate maintainer possible
>> * just seems more logical to have it separated ;)
>
> The downside is you have to change the URL in kaffeine sources as
> kaffeine generates its scan file from that repo (on the server side and
> the client downloads then http://kaffeine.kde.org/scanfile.dvb.qz).
>
>> This obviously should find a nice home on linuxtv where it belongs!
>
> At best.
>
>> Here is my personal repository with the work I mentioned done.
>> git://git.schinagl.nl/dvb_frequency_scanfiles.git
>>
>> If an issue is that none of the original maintainers are not looking
>> forward to do the job, I am willing to take maintenance on me for now.
>
> Ping? Anybody? I would help with that too as I hate resending patches.
> But the first step I would do is a conversion to GIT. HG is demented to
> begin with.
>
> --
> js

Re: [RFC] Initial scan files troubles and brainstorming

[Manu Abraham]

On Mon, Jan 7, 2013 at 6:23 PM, Christoph Pfister
<christophpfister@gmail.com> wrote:
> Okay guys, I think this is a good time to discuss scan file
> maintenance [ should have taken care of it earlier, but well ...].
>
> I've been updating the scan data for the past few years, but found
> barely no time in the last (many!) months. This won't change in
> future, so I've decided to step down from the task; may others do what
> is necessary ...

Christoph, It's unfortunate that you decided to drop the ball.
I will try to take care of it in the meanwhile..

Regards,
Manu

Re: [RFC] Initial scan files troubles and brainstorming

[Jonathan McCrohan]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

Hi Christoph,

On Mon, 7 Jan 2013 13:53:25 +0100, Christoph Pfister wrote:
> I've been updating the scan data for the past few years, but found
> barely no time in the last (many!) months. This won't change in
> future, so I've decided to step down from the task; may others do what
> is necessary ...

Thanks for your work over the past few years. If nobody else is willing,
I'd be happy to take over this role, and if Oliver's offer still stands,
I'd be happy to share DVB scanfile maintenance with him.

Jon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: [RFC] Initial scan files troubles and brainstorming

[Oliver Schinagl]

On 07-01-13 23:44, Jonathan McCrohan wrote:
> Hi Christoph,
>
> On Mon, 7 Jan 2013 13:53:25 +0100, Christoph Pfister wrote:
>> I've been updating the scan data for the past few years, but found
>> barely no time in the last (many!) months. This won't change in
>> future, so I've decided to step down from the task; may others do what
>> is necessary ...
> Thanks for your work over the past few years. If nobody else is willing,
> I'd be happy to take over this role, and if Oliver's offer still stands,
> I'd be happy to share DVB scanfile maintenance with him.
Slightly depends on where this goes. If there is a seperated 
dvb-scanfile tree (or whatever incarnation can be thought of) I'd be 
happy to help out where I can.

The repository is 'done' imo. History is preserved and seperated out. 
Would just need some word from the powers that be. :)
> Jon

Re: [RFC] Initial scan files troubles and brainstorming

[Johannes Stezenbach]

On Mon, Jan 07, 2013 at 01:53:25PM +0100, Christoph Pfister wrote:
> 
> @Johannes: As I don't need the account anymore, please delete it.

Done.

Thanks for the work you put into it!

Johannes