Winfried, On Mon, 9 Mar 2009 18:10:56 -0400 Devin Heitmueller <devin.heitmueller@xxxxxxxxx> wrote: > On Mon, Mar 9, 2009 at 6:03 PM, wk <handygewinnspiel@xxxxxx> wrote: > > Its a bad idea to expect someone else, the magic volunteer, doing work with > > *deep impact* on the dvb driver API structure or documentation. > > Working on this topic determines complete usability of the driver, so MAIN > > DEVELOPERS have to REVIEW and CONTRIBUTE. > > If they think, that they cannot do such work in parallel, they should to > > stop work on drivers for some time. > > Cut me a $25,000 check and I'll happily do it. Otherwise, don't tell > a bunch of volunteer developers how they should be spending their > time. What you happen to think is the important is not necessarily > what developers feel is the most valuable use of their time. > > The reality is that there is *some* value a developer can contribute > in reviewing the content and providing feedback and a *TON* of grunt > work involved that can be done by anybody who takes the time to learn > docbook. If someone wants to volunteer to do the former, I'm sure > some developers would be willing to do the latter. I agree with Devin. The format conversion itself doesn't aggregate value to the spec. It is just a format conversion. Even the merge between V4L and DVB specs doesn't aggregate much value, per se. The value of a merged docbook with V4L and DVB will appear when some new chapters will be added, mentioning how a hybrid driver should work to provide both APIs, and maybe creating some additional functions to control the hybrid behaviour (if needed). I doubt that you'll find a main developer to do the docbook conversion work, instead of spending his time developing. There are a number of reasons for that, including that developers are good with C language but are probably not familiar with docbook/latex languages. Also, they are not as skilled on writing a book in English than on writing a C file. A proof of this is that most of the work on both V4L and DVB APIs were done by a very small subset of people. So, the better is to have someone more focused with documentation that will do the hard work, with the support of the developers that will review and help with the contents of the document, fixing the non-compliances (at the code, or by proposing a patch to the docs). 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
