Oliver Endriss wrote: > On Sunday 16 May 2010 03:53:48 hermann pitton wrote: >> Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling >> Landgraf: >>> Hello Oliver, >>> >>> On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss <o.endr...@gmx.de> wrote: >>>> On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote: >>>>> On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: >>>>>>> Am 22.3.2010 20:34, schrieb e9hack: >>>>>>>> Am 20.3.2010 22:37, schrieb Hans Verkuil: >>>>>>>>> On Saturday 20 March 2010 17:03:01 e9hack wrote: >>>>>>>>> OK, I know that. But does the patch I mailed you last time fix this >>>>>>>>> problem >>>>>>>>> without causing new ones? If so, then I'll post that patch to the >>>>>>>>> list. >>>>>>>> With your last patch, I've no problems. I'm using a a TT-C2300 and a >>>>>>>> Budget card. If my >>>>>>>> VDR does start, currently I've no chance to determine which module is >>>>>>>> load first, but it >>>>>>>> works. If I unload all modules and load it again, I've no problem. In >>>>>>>> this case, the >>>>>>>> modules for the budget card is load first and the modules for the FF >>>>>>>> loads as second one. >>>>>>> Ping!!!!!! >>>>>> It's merged in Mauro's fixes tree, but I don't think those pending >>>>>> patches >>>>>> have been pushed upstream yet. Mauro, can you verify this? They should be >>>>>> pushed to 2.6.34! >>>>> What about the HG driver? >>>>> The v4l-dvb HG repository is broken for 7 weeks... >>>> Hi guys, >>>> >>>> we have May 16th, and the HG driver is broken for 10 weeks now! >>>> >>>> History: >>>> - The changeset which caused the mess was applied on March 2nd: >>>> http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f >>>> >>>> - A fix is waiting at fixes.git since March 24th: >>>> >>>> http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 >>>> >>>> Are there any plans to bring v4ldvb HG to an usable state? >>> Yes, Now I will collect patches from devel and fixes tree. At least >>> until we achieve a better approach on it. >>> Sorry the delay. >>> >>> Sounds good? Any other suggestion? >>> >>> Let me work on it. >>> >>> Cheers >>> Douglas >> >> Hi, Douglas and Oliver, >> >> just as a small comment. >> >> I have not been on latest rc1 and such rcs close to a release for some >> time. >> >> But I was for a long time and v4l-dvb can't be a substitute for such. > > Sorry, I do not want to cope with experimental kernels and their bugs on > my systems. I need a stable and reliable platform, so that I can > concentrate on 'my' bugs. > > Usually I update the kernel every 3..4 releases (which causes enough > trouble due to changed features, interfaces etc).
I used to do it, but, in fact updating every release and following stable worked better for me, since there are less changes at the features, making easier to compile a new kernel that won't break anything. Anyway, it is up to you to use whatever works better for you. > >> Despite of getting more users for testing, on _that_ front does not >> happen such much currently, keeping v4l-dvb is mostly a service for >> developers this time. >> >> So, contributing on the backports and helping Douglas with such is >> really welcome. > > I confess that I do not know much about the tree handling procedures of > the kernel. Imho it sounds crazy to have separate 'fixes' and > 'development' trees. I'll change the procedures for 2.6.35. I'll basically opt for having topic branches (for example, having a "ngene" branch), where all ngene patches will be applied, updating "master" only after having those patches in kernel. I'll likely create a stable branch, with the latest kernel, plus all patches (like v2.6.34-v4l-dvb), to help people that want to develop using git. The big problem when handling patches upstream is caused by rebasing a patch, and the higher number of patches in a tree, the higher is the probability that a rebase will needed to avoid breaking compilation on a bisect. To give you an example, one big series of patches moved slab.h into each driver that uses malloc. If a new driver or c file that needs this include on our series were added, to avoid breaking bisect, we need to go to the patch that introduced this code, and add the include there. All patches after this one needs to be rebased, when submitting upstream. So, let's say that the original patch has 05a43 has, and the new patch has a0342 (fictional numbers). So, in the development branches, this patch is known as 05a43, where, on upstream, this patch will be known as a0342. If I rebase the development tree, all developers using git would need to rebase their trees. If I don't rebase, after merging from upstream, this patch will appear 2 times at the master branch history: as 05a43 and as a0342. To be worse, on the next time I need to send patches upstream, this patch will appear again on my pile of patches to be submitted, and I'll need to manually drop it. Due to 2.6.33 merge, this problem is already present on our master branch. So, I'll need to drop a big pile of patches on my next upstream pull request. At each new kernel release, things would become worse. With topic branches, things will hopefully become easier, as people can base their trees on a topic branch. Also, we may have some topic branches based on a stable release, and others based on upstream, but it will require me to maintain separate development branches with all merging patches per kernel release. > > A developer's tree (no matter whether HG or GIT) must also include the > fixes, otherwise it is unusable. You cannot wait until applied fixes > flow back from the kernel. > > Btw, the v4ldvb HG repositories contain tons of disabled code (marked > '#if 0'), which was stripped for submission to the kernel. > Even if we would switch to GIT completely, we need a separate GIT > repository which would hold the original code. This is due to a policy we had at -hg time: not pollute upstream with dead code garbage. Maybe we may have a topic branch with all those dead code, but I think that, before adding those code on kernel, we need to review what will be added there: there are _lots_ of such #if 0 code that is there for years and were never touched (in a matter of fact, this is the typical case). It seems valuable to do a cleanup first, at -hg, removing the ones that are there for ages and that nobody is interested on working it, and just drop at -hg. It will still be there forever, at -hg history, but the source files will be cleaner without those useless code. In the specific case of ngene, where stoth and devin are working to enable most of those dead code, I'll seek for an approach that will add those #if 0 code before applying the patches that will fix that code, in order to have a better history at -git, when they submit their next pull request. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
