Re: [RFC] Initial scan files troubles and brainstorming

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/11/13, Jiri Slaby <jirislaby@xxxxxxxxx> wrote:
> On 01/10/2013 06:40 PM, Manu Abraham wrote:
>> On 1/9/13, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote:
>>> Em Wed, 9 Jan 2013 06:08:44 -0500
>>> Michael Krufky <mkrufky@xxxxxxxxxxx> escreveu:
>>>
>>>> On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab
>>>> <mchehab@xxxxxxxxxx> wrote:
>>>>> Em Wed, 09 Jan 2013 10:43:23 +0100
>>>>> Oliver Schinagl <oliver+list@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux