Em Thu, 10 Jan 2013 23:57:42 +0100 Oliver Schinagl <oliver+list@xxxxxxxxxxx> escreveu: > 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. 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 -- 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
