Re: [RFC] Initial scan files troubles and brainstorming

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

 



On Thu, Jan 10, 2013 at 1:46 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:
> 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

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