Johannes Stezenbach wrote: >The other difference is your use of dvb-pll. I think it was a conscious >decision to move PLL handling out of the frontend drivers (thus they are >now just "demodulator drivers") and into the adapter drivers. I would >have expected that you use dvb-pll from the cx88 driver, and not add >PLL handling back to cx22702. So in essence the usage of the >cx22702 driver in the adapter drivers is different from the >usage of the other demodulator drivers. > > On most modern cards (ancient ones like the ves1820 based, more modern ones like the TDA10045-based ones, and really new ones like the MT352-based Pinnacle 300i) the PLL settings depend on the external circuitry and cannot really get shared between different hardware designs. So there are several people who expressed serious doubths whether a PLL library makes sense, please see the mailing list archives for details. Dito for the i2c registration. >>>but also social problems with the people who were involved in the >>>discussions that led to the current frontend design. >>> >>> >>The discussion was about the frontend _interface_ design, i.e. how the >>modules talk to each other, how they are configured and so on. I >>can't remember having discussed any strict coding guidelines for the >>driver internals. >> >> > >I remember it different, but could be wrong (and I don't have the >time to re-read the giant "refactoring" and "CX88 i2c issue w/ >DVB tuners" threads to find out). Anyway, Andrew invested lots >of time to rework the drivers according to what he thought the >concensus was, and now you come and try to invalidate (part of) >his work. > >I don't get why you can't just send a small patch to get the >cx22702 driver to work, and then in a second step start a discussion >to convert *all* frontend drivers to use i2c_client, outlining >the improvements that would make for all. (The first step >shouldn't be too difficult given that you claim that the use >of i2c_client is just an internal implementation thing.) > > open source software always depends on some social competence, it's easy to get working projects to a halt by simply trying to force all involved developers on "the one and only golden path". Unless development follows the rules of a sane common sense and design decisions let less-involved and new developers recognise some "natural" structure that makes sense from the technical point of view you'll be one day the only one maintaining the code. Introducing dead (in the sense of in 99% of all installations unused) code just because it's "nice" and shows up in some rarely or never used filesystems, because it's "politically correct to do it this way", because "the lkml folks want to see it this way" will sooner or later make things hard to maintain and lead to single-developer projects. >>>An easy way out: You could get a CVS account and commit it >>>yourself. That way you would take direct responsibility for >>>your deeds. >>> >>> >>I don't see how that makes a difference. Either I care about that >>baby or I don't, whenever I do by mailing patches or by commiting >>myself doesn't really matter I think. Well, committing directly would >>bypass peer review, I don't think that is good (look at the mt352 >>discussion for example ...), you guys know the dvb internals much >>better than I do. >> >> > >Well, I get the feeling that you try to ignore my peer review (in >the cx22702 case). >With a CVS account you could still post your patches for review before >comitting them, but our lameness wouldn't keep you from proceeding. > > Responsible developers should always get a CVS account, this makes things much easier. Johannes, do you create one for Gerd? Holger
