On Thu, Jul 12, 2007 at 03:49:30AM +1000, Julian wrote: > Since this disscussion is public... > I'm going to put in my 2 cents. > > If you actually read his posts - Like alot of end users are. Its the flames > and personal attacks that are coming from the group mentality here (im sure > theres a wiki that can explain that too)
Hm, Markus complains that the community doesn't work, and you're complaining that it _does_ work -- or what do you mean by "group mentality"? > So if we are talking about changes to the core and how v4l and dvb devices > will work under linux in the future. He/they with the best solution will win > via non-bias peer review and hopefully *beyond* the linuxtv project. So if > Markus persists enough (he seems the only one consistently reworking what he > has already done - but everyone seems to skim past that in his posts...) he > will succeed. > > I admire anyone that makes an effort against the status quo that fails to > move > anywhere really, and spends more effect resisting any kind of change than > actually doing anything or offering an alternative. > > Just because he is outnumbered with support here means absolutely nothing. > May the best code win. Markus always portrays it that way, that there is a group of evil guys who block his code, who mislead him, who want to retain the status quo etc. pp. And now he is the lonely hero who stands up against the establishment... IMHO that is complete rubbish. There isn't even a formal group of "linuxtv core developers". I'm glad that Mauro agreed to merge the DVB and V4L trees into one, and to do the patch handling for the combined tree. And I'm glad Mike and Trent do a lot of patch review and bugfixing work, unseen and unrewarded my most people. Does that give them any authority to ACK and NACK patches as they see fit? Hell, no! But the community process works that way that if someone reviews a patch and has objections, then these objections must either be addressed or shown to be wrong. (Read Documentation/ManagementStyle in the kernel to see how it works ;-) In Markus case, serveral people who looked at his patches had objections, but he refused to address them, but was unable to either show the objections as being wrong, or get a _single_ other developer to back up his position. Instead there were threats to "fork the linuxtv project" if his code wouldn't get merged... The sad thing is that only a relatively small part of Markus' code has problems, and the bulk of it could have been merged without it, leaving out the xc3028 v4l/dvb arbitration functionality. But Markus didn't want this. Anyway, there are many patches which are rejected from the Linux kernel or have to go through significant transformations before they are allowed into the kernel. You should read the linux kernel mailing list for a while, maybe you'd then see that the entry level for patches into v4l/dvb is fairly low compared to the high standards required for core kernel code like scheduler, timekeeping, networking, VM, block IO layer etc. > >Your attempts to force the merge with flames and ultimatums > >(yes, plural) failed. Surprise, surprise... > > how soft do people get with their drivers that they see a patch submission - > as a flame? That's not what I said, I can tell a patch submission from a flame quite well, thanks. Johannes _______________________________________________ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
