On 01/10/13 23:11, Mauro Carvalho Chehab wrote:
Em Thu, 10 Jan 2013 21:51:29 +0100
Oliver Schinagl <oliver+list@xxxxxxxxxxx> 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
--
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
