On Mon, Feb 05, 2007 at 11:30:17AM +0100, Hans Verkuil wrote: > > I'm building packages for RHEL and FC as appropriate, they will land > > in atrpms-testing. > > Be aware of the new encoder firmware included with the package!
I was always packaging v4l-cx2341x-init.mpg, or is there something else now? > > > My intention is to release a ivtv-0.18.0 for kernel 2.6.18, 0.19.0 > > > for kernel 2.6.19 and a 0.20.0 for kernel 2.6.20. This keeps the > > > numbering nicely regular. There will probably also be a 0.21.0 for > > > kernel 2.6.21, > > > > If it wouldn't be a too big issue I would recommend using the same > > versioning throughout all supported kernels. I think it makes the > > users' handling easier, as well as for people reviewing the code, > > e.g. it is easier to review some conditionals based on kernel > > versions than to have several trees. > > > > It also makes packaging far more easier, as the userland portions > > remain in the same versioned subpackage, even if people have both > > 2.6.18 and 2.6.19 kernels and ivtv kernel subpackages installed. > > True, but on the other hand it is much more like what it will be when > the driver enters the kernel: only limited fixes for older kernels. But > I'm not yet certain how to handle this. Once the driver is in the kernel I wouldn't backport small fixes at all, I would simply move along with development of a single version while allowing the software to build for a certain kernel range, e.g. if certain APIs from 2.6.18 are needed then 2.6.18 upwards. If a small number of conditionals allow for a broader range of kernel that's OK (e.g. as long as the pain is small compared to the gain). That's the typical model followed by many projects, whether they are in the kernel already with some version or not, e.g. alsa, ipw*, v4l etc. It makes talking about features entering the driver easier, e.g. instead of "super-foo was added to 0.24.5, 0.25.2 and 0.26rc1" one would just have a single version. Having the version stick to the software itself and not correlate with the kernel version has also other benefits: Once it hits say 2.6.22 as an internal kernel module it would carry a modversion of 0.22.0. Perhaps 2.6.23 will see no changes at all, but the users will be confused about still being on 0.22.0 because they have been educated to associate the version of the module with that of the kernel's and also have been warned not to mix. And users could check whether their in-kernel or OOT version supports "super-foo" by the same kernel-independent method, a simple modinfo ivtv | grep ^version: -- Axel.Thimm at ATrpms.net
pgpXFAKsCYc88.pgp
Description: PGP signature
_______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
