Results of the 'dropping support for kernels <2.6.22' poll

Results of the 'dropping support for kernels <2.6.22' poll

[Hans Verkuil]

Hi all,

Well, the polling station closed and the results are:

Yes: 32
No: 3

First of all thanks to all who responded! To be honest, I was quite 
surprised at the number of votes received as I hadn't expected to get so 
many. Thank you!

It was very interesting to read the reasons given for the yes or no vote. 
Basically, all the Yes votes boiled down to this reply given by David 
Ellingsworth:

"As others have already pointed out, it is a waste of time for developers 
who volunteer their time to work on supporting prior kernel revisions for 
use by enterprise distributions. The task of back-porting driver 
modifications to earlier kernels lessens the amount of time developers can 
focus on improving the quality and stability of new and existing drivers. 
Furthermore, it deters driver development since there an expectation that 
they will back-port their driver to earlier kernel versions. Finally, as a 
developer, I have little interest in what was new yesterday. I usually run 
the latest kernel whenever possible and for a number of different reasons. 
Some of those reasons include better hardware support, bug detection, and 
stability testing. All services greatly valued by other kernel developers."

Note that of the people that voted Yes about 10-15 are developers, and the 
others are users of v4l-dvb. It's a bit imprecise since some of the people 
who voted did contribute the occasional fix in the past, but are not active 
developers. It's a bit of a grey area.

The three No votes (all from developers) boiled down to this reply from 
Douglas Schilling Landgraf:

"I know it's not easy task keep this support working... but we still have 
*users* around the world using kernel < 2.6.22 (as some of them already 
reported this)."

It will come as no surprise when I say that I think that is not sufficient 
reason for supporting kernels < 2.6.22. There are no doubt users still on 
kernel 2.4 as well or even older. Yet we do not support those.

There are good reasons as a developer for keeping backwards compatibility 
with older kernels:

1) a larger testers base.
2) that warm feeling you get when users can get their new card to work with 
just v4l-dvb without having to upgrade their kernel.
3) as a developer you do not need to update to the latest kernel as well. 
Very useful if the latest kernel introduces a regression on your hardware 
as happened to me in the past.

There are also disadvantages:

1) it takes (unpaid!) time and effort to maintain the backward 
compatibility.
2) as time goes by the code becomes ever harder to maintain due to the 
accumulated kernel checks.
3) the additional complication of backwards compatibility code might deter 
new developers.

There has to be a balance here. Currently it is my opinion that I'm spending 
too much time on the backwards compat stuff. And that once all the i2c 
modules are converted to the new framework both the maintainability and the 
effort required to maintain the compat code will be improved considerably 
by dropping support for kernels <2.6.22.

Yes, the testers base will be reduced by this, but I believe that the vast 
majority of our users will not be affected by this. The poll did nothing to 
change my mind on this. The one argument I've seen that I thought had merit 
was with regards to netbooks, and the Asus eeePC in particular. Apparently 
that distro uses 2.6.21 and whether that will be upgraded to a newer kernel 
in the future is dubious.

But in the end it is really the same story: where do you put the line? If 
the eeePC will never receive an update, does that mean we have to keep 
maintaining support for 2.6.21 for many years to come? That's ridiculous 
IMHO.

I think that my proposal to do our best to support the actively maintained 
releases of the three top-distros makes sense. It will cater to the 
majority of users, and limits the amount of work we need to do. And we know 
that ugly workarounds can always be removed after a certain amount of time.

In the final analysis I'm the boss of my own time. And I've decided that 
once the conversion of all the i2c modules is finished I'll stop spending 
time on the compatibility code for kernels <2.6.22 as it is simply no 
longer an effective use of my time. If someone else wants to spend time on 
that, then that's great and I will of course answer questions or help in 
whatever way is needed.

I know that Mauro thinks he can keep the backwards compat code in by doing 
nifty code transformations. It would be nice if he succeeds (and I have no 
doubt that it is possible given enough time and effort), but personally I 
think it is time better spent elsewhere.

A final note regarding distros: we as v4l-dvb developers do not owe them 
anything. We are not paid by them to provide support to their products. 
It's *their* task to do so. If they want backwards compatibility for older 
kernels, then they can assign and pay a developer to work on that.

So any argument along the lines of 'we need to support users of distro X' is 
a false argument. It's the responsibility of distro X to support their 
users. It definitely is not our responsibility.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Results of the 'dropping support for kernels <2.6.22' poll

[kilgota]

On Mon, 2 Mar 2009, Hans Verkuil wrote:

<snip>
> [...] The one argument I've seen that I thought had merit
> was with regards to netbooks, and the Asus eeePC in particular. Apparently
> that distro uses 2.6.21 and whether that will be upgraded to a newer kernel
> in the future is dubious.
>
> But in the end it is really the same story: where do you put the line? If
> the eeePC will never receive an update, does that mean we have to keep
> maintaining support for 2.6.21 for many years to come? That's ridiculous
> IMHO.

Hans,

Just one comment. IIRC, I was the one who mentioned the eeePC, having 
recently bought one. I mentioned it, not because I disagree with anything 
else you write here, but because, in fact, I agree. Frankly, I think the 
use of the 2.6.21 kernel in the eeePC is somewhat perverse and just a 
little bit weird.

Essentially, the eeePC and the other Intel-based netbooks are not some 
kind of exotic hardware platforms, which might provide an explanation or 
excuse for using some "specially crafted" but old kernel. No. In fact, the 
eeePC and almost all the other current netbooks are just a new (and 
attractive) combination of some fairly standard types of hardware. 
Practically every hardware component in them is better supported in more 
recent kernels, with the possible exception of a wireless device which may 
not yet be supported in any kernel, new or old. Therefore, instead of 
worrying about whether to support and provide indulgence for apparently 
inexplicable behavior, let us hope that a decision of this nature will 
serve as a needed message.

Theodore Kilgore

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Mon, 2 Mar 2009, Hans Verkuil wrote:
> There are good reasons as a developer for keeping backwards compatibility
> with older kernels:

Do you mean no backwards compatibility with any older kernels?  Or do you
mean just dropping support for the oldest kernels now supported.  What
you've said above sounds like the former.

> 1) a larger testers base.
> 2) that warm feeling you get when users can get their new card to work with
> just v4l-dvb without having to upgrade their kernel.
> 3) as a developer you do not need to update to the latest kernel as well.
> Very useful if the latest kernel introduces a regression on your hardware
> as happened to me in the past.

It's also very useful for working on/testing multiple trees.  I can test
your zoran tree, switch to a different tree for some cx88 work, and then
switch back to a know good tree to record some tv shows tonight.  I can
switch back and forth between your zoran tree and a months older one in
*seconds* to check differences in behavior.  Without having to reboot two
dozen times a day to a half dozen different kernels.

For the most part the v4l-dvb compat system works behind the scenes very
well.  I'm sure there have been cases where a developer who doesn't reboot
hourly to the latest git kernel produced a patch that wouldn't have worked
on the kernel they were themselves using if the compat system hadn't made
it work automatically without the developer even knowing.

> 2) as time goes by the code becomes ever harder to maintain due to the
> accumulated kernel checks.

Unless you want to maintain backwards compat forever, the idea is to reach
some kind of equilibrium were old compat code is removed at the same rate
new compat code is added.

> 3) the additional complication of backwards compatibility code might deter
> new developers.

But needing to run today's kernel and have your closed source video card
driver stop working might deter developers who just want to produce a few
small patches.

> There has to be a balance here. Currently it is my opinion that I'm spending
> too much time on the backwards compat stuff. And that once all the i2c
> modules are converted to the new framework both the maintainability and the
> effort required to maintain the compat code will be improved considerably
> by dropping support for kernels <2.6.22.

Will you allow drivers to use a combination of probe based and detect based
i2c using the new i2c api?  It's my understanding that you only support the
new i2c api for probe-only drivers.  Probe/detect or ever detect-only
drivers for the new i2c api haven't been done?  I think much of the
difficulty of supporting <2.6.22 will be solved once there is a way to
allow drivers to use both probe and detect with the new api.

I think I would have gone about it from the other side.  Convert bttv to
use detect and then make that backward compatible.  That compatibility
should be much easier and less invasive.

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Simon Kenyon]

kilgota@banach.math.auburn.edu wrote:
> Just one comment. IIRC, I was the one who mentioned the eeePC, having 
> recently bought one. I mentioned it, not because I disagree with 
> anything else you write here, but because, in fact, I agree. Frankly, 
> I think the use of the 2.6.21 kernel in the eeePC is somewhat perverse 
> and just a little bit weird.
>
> Essentially, the eeePC and the other Intel-based netbooks are not some 
> kind of exotic hardware platforms, which might provide an explanation 
> or excuse for using some "specially crafted" but old kernel. No. In 
> fact, the eeePC and almost all the other current netbooks are just a 
> new (and attractive) combination of some fairly standard types of 
> hardware. Practically every hardware component in them is better 
> supported in more recent kernels, with the possible exception of a 
> wireless device which may not yet be supported in any kernel, new or 
> old. Therefore, instead of worrying about whether to support and 
> provide indulgence for apparently inexplicable behavior, let us hope 
> that a decision of this nature will serve as a needed message.
just as another data point
i have an eee 900 and i run gentoo on it
i have 2.6.27 running just fine (wireless and all)

i know gentoo is a little too hardcore for most people
but living with a distro kernel forever is not a real requirement
--
simon

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Hans Verkuil]

On Monday 02 March 2009 23:47:31 Trent Piepho wrote:
> On Mon, 2 Mar 2009, Hans Verkuil wrote:
> > There are good reasons as a developer for keeping backwards
> > compatibility with older kernels:
>
> Do you mean no backwards compatibility with any older kernels?  Or do you
> mean just dropping support for the oldest kernels now supported.  What
> you've said above sounds like the former.

This was about the advantages of having compat code at all to support 
kernels other than the bleeding edge git kernel.

> > 1) a larger testers base.
> > 2) that warm feeling you get when users can get their new card to work
> > with just v4l-dvb without having to upgrade their kernel.
> > 3) as a developer you do not need to update to the latest kernel as
> > well. Very useful if the latest kernel introduces a regression on your
> > hardware as happened to me in the past.
>
> It's also very useful for working on/testing multiple trees.  I can test
> your zoran tree, switch to a different tree for some cx88 work, and then
> switch back to a know good tree to record some tv shows tonight.  I can
> switch back and forth between your zoran tree and a months older one in
> *seconds* to check differences in behavior.  Without having to reboot two
> dozen times a day to a half dozen different kernels.
>
> For the most part the v4l-dvb compat system works behind the scenes very
> well.  I'm sure there have been cases where a developer who doesn't
> reboot hourly to the latest git kernel produced a patch that wouldn't
> have worked on the kernel they were themselves using if the compat system
> hadn't made it work automatically without the developer even knowing.
>
> > 2) as time goes by the code becomes ever harder to maintain due to the
> > accumulated kernel checks.
>
> Unless you want to maintain backwards compat forever, the idea is to
> reach some kind of equilibrium were old compat code is removed at the
> same rate new compat code is added.

Right.

> > 3) the additional complication of backwards compatibility code might
> > deter new developers.
>
> But needing to run today's kernel and have your closed source video card
> driver stop working might deter developers who just want to produce a few
> small patches.
>
> > There has to be a balance here. Currently it is my opinion that I'm
> > spending too much time on the backwards compat stuff. And that once all
> > the i2c modules are converted to the new framework both the
> > maintainability and the effort required to maintain the compat code
> > will be improved considerably by dropping support for kernels <2.6.22.
>
> Will you allow drivers to use a combination of probe based and detect
> based i2c using the new i2c api?  It's my understanding that you only
> support the new i2c api for probe-only drivers.  Probe/detect or ever
> detect-only drivers for the new i2c api haven't been done?  I think much
> of the difficulty of supporting <2.6.22 will be solved once there is a
> way to allow drivers to use both probe and detect with the new api.

The difficulties are not with probe or detect, but with the fact that with 
the new API the adapter driver has to initiate the probe instead of the 
autoprobing that happened in the past by just loading the i2c module. The 
compat issues are for the most part limited to the i2c modules themselves, 
since those changed the most because of this.

I don't think we have to use the detect() functionality at all in i2c 
modules, although I need to look at bttv more closely to see whether that 
is a true statement. I'm at this moment opposed to the use of detect() 
since I fear it can lead to pretty much the same problems as autoprobing 
does when you start to rely on it. It's meant for legacy code where proper 
device/address information is not present. In the case of v4l-dvb the only 
driver that might qualify is bttv.

> I think I would have gone about it from the other side.  Convert bttv to
> use detect and then make that backward compatible.  That compatibility
> should be much easier and less invasive.

This wouldn't have made any difference at all.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Tue, 3 Mar 2009, Hans Verkuil wrote:
> On Monday 02 March 2009 23:47:31 Trent Piepho wrote:
> > On Mon, 2 Mar 2009, Hans Verkuil wrote:
> > > There are good reasons as a developer for keeping backwards
> > > compatibility with older kernels:
> >
> > Do you mean no backwards compatibility with any older kernels?  Or do you
> > mean just dropping support for the oldest kernels now supported.  What
> > you've said above sounds like the former.
>
> This was about the advantages of having compat code at all to support
> kernels other than the bleeding edge git kernel.

I thought the poll was only about dropping support for kernels older than
2.6.22?

> > Will you allow drivers to use a combination of probe based and detect
> > based i2c using the new i2c api?  It's my understanding that you only
> > support the new i2c api for probe-only drivers.  Probe/detect or ever
> > detect-only drivers for the new i2c api haven't been done?  I think much
> > of the difficulty of supporting <2.6.22 will be solved once there is a
> > way to allow drivers to use both probe and detect with the new api.
>
> The difficulties are not with probe or detect, but with the fact that with
> the new API the adapter driver has to initiate the probe instead of the
> autoprobing that happened in the past by just loading the i2c module. The

That's not true.  Using the new API's ->probe() method works like you say,
but using the new API's ->detect() method is much more like the autoprobing
that happened in the past.

> I don't think we have to use the detect() functionality at all in i2c
> modules, although I need to look at bttv more closely to see whether that
> is a true statement. I'm at this moment opposed to the use of detect()
> since I fear it can lead to pretty much the same problems as autoprobing
> does when you start to rely on it. It's meant for legacy code where proper
> device/address information is not present. In the case of v4l-dvb the only
> driver that might qualify is bttv.

In some cases there is no way to identify the what hardware a card has and
there is also new cards that are still unknown.

> > I think I would have gone about it from the other side.  Convert bttv to
> > use detect and then make that backward compatible.  That compatibility
> > should be much easier and less invasive.
>
> This wouldn't have made any difference at all.

But you said yourself that the difficulties are "with the fact that with
the new API the adapter driver has to initiate the probe instead of the
autoprobing that happened in the past." Converting the bttv driver to use
detect with the new API would avoid those difficulties.

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Mauro Carvalho Chehab]

Hans,

On Mon, 2 Mar 2009 22:18:24 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> In the final analysis I'm the boss of my own time. And I've decided that 
> once the conversion of all the i2c modules is finished I'll stop spending 
> time on the compatibility code for kernels <2.6.22 as it is simply no 
> longer an effective use of my time. If someone else wants to spend time on 
> that, then that's great and I will of course answer questions or help in 
> whatever way is needed.
> 
> I know that Mauro thinks he can keep the backwards compat code in by doing 
> nifty code transformations. It would be nice if he succeeds (and I have no 
> doubt that it is possible given enough time and effort), but personally I 
> think it is time better spent elsewhere.

It required just a couple of hours today, in order to add the I2C conversion
rules on the backport tree:

	http://linuxtv.org/hg/~mchehab/backport/

There, I used, as example, the tea6415c.c file that you sent me, meant to be an
example of a driver converted to use just the new I2C API. I've removed from it
all the other #ifdefs for 2.6.26, so, the module doesn't have any compat bits
(except for "compat.h" that can also be handled by the script). I didn't compile
the entire tree, since several drivers will break, as they aren't ported yet
to the new I2C style.

Maybe a few adjustments on the backport.pl may be needed, after having all
drivers converted to 2.6.22, since the final version may need some other
patching rules.

That's said, the backport tree is still an experimental work. The scripts
require more time to be tested, and the Makefiles need some cleanups.

Beside the fact that we don't need to strip support for legacy kernels, the
advantage of using this method is that we can evolute to a new development
model. As several developers already required, we should really use the
standard -git tree as everybody's else. This will simplify a lot the way we
work, and give us more agility to send patches upstream.

With this backport script, plus the current v4l-dvb building systems, and after
having all backport rules properly mapped, we can generate a "test tree"
based on -git drivers/media, for the users to test the drivers against their
kernels, and still use a clean tree for development.

Cheers,
Mauro

--

PS: the tea6415c.c fully ported to the new I2C API you sent in priv
doesn't compile fine with 2.6.28. Since this file is just an example, I didn't
care to fix it.

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Guennadi Liakhovetski]

On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote:

> Beside the fact that we don't need to strip support for legacy kernels, the
> advantage of using this method is that we can evolute to a new development
> model. As several developers already required, we should really use the
> standard -git tree as everybody's else. This will simplify a lot the way we
> work, and give us more agility to send patches upstream.
> 
> With this backport script, plus the current v4l-dvb building systems, and after
> having all backport rules properly mapped, we can generate a "test tree"
> based on -git drivers/media, for the users to test the drivers against their
> kernels, and still use a clean tree for development.

Sorry, switching to git is great, but just to make sure I understood you 
right: by "-git drivers/media" you don't mean it is going to be a git tree 
of only drivers/media, but it is going to be a normal complete Linux 
kernel tree, right?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote:
> > Beside the fact that we don't need to strip support for legacy kernels, the
> > advantage of using this method is that we can evolute to a new development
> > model. As several developers already required, we should really use the
> > standard -git tree as everybody's else. This will simplify a lot the way we
> > work, and give us more agility to send patches upstream.
> >
> > With this backport script, plus the current v4l-dvb building systems, and after
> > having all backport rules properly mapped, we can generate a "test tree"
> > based on -git drivers/media, for the users to test the drivers against their
> > kernels, and still use a clean tree for development.
>
> Sorry, switching to git is great, but just to make sure I understood you
> right: by "-git drivers/media" you don't mean it is going to be a git tree
> of only drivers/media, but it is going to be a normal complete Linux
> kernel tree, right?

So there will be no way we can test a driver without switching to a new
kernel hourly?  And there is no way we can test someone else's tree without
compiling an entirely new kernel and rebooting?  And every tree we want to
work on requires a complete copy of the entire kernel source?

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Guennadi Liakhovetski]

On Thu, 5 Mar 2009, Trent Piepho wrote:

> On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> > On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote:
> > > Beside the fact that we don't need to strip support for legacy kernels, the
> > > advantage of using this method is that we can evolute to a new development
> > > model. As several developers already required, we should really use the
> > > standard -git tree as everybody's else. This will simplify a lot the way we
> > > work, and give us more agility to send patches upstream.
> > >
> > > With this backport script, plus the current v4l-dvb building systems, and after
> > > having all backport rules properly mapped, we can generate a "test tree"
> > > based on -git drivers/media, for the users to test the drivers against their
> > > kernels, and still use a clean tree for development.
> >
> > Sorry, switching to git is great, but just to make sure I understood you
> > right: by "-git drivers/media" you don't mean it is going to be a git tree
> > of only drivers/media, but it is going to be a normal complete Linux
> > kernel tree, right?
> 
> So there will be no way we can test a driver without switching to a new
> kernel hourly?  And there is no way we can test someone else's tree without
> compiling an entirely new kernel and rebooting?  And every tree we want to
> work on requires a complete copy of the entire kernel source?

AFAIR, Mauro wanted to provide snapshots for those who absolutely prefer 
to work with partial trees. Although, to be honest, I don't understand 
what makes video drivers so special. Think about audio drivers, or 
network, including WLAN. I never heard about those subsystems working with 
or providing subtree snapshots. If only before specific drivers or 
subsystems are included in the mainline, but not long after that.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> On Thu, 5 Mar 2009, Trent Piepho wrote:
> > On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> > > On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote:
> > > > Beside the fact that we don't need to strip support for legacy kernels, the
> > > > advantage of using this method is that we can evolute to a new development
> > > > model. As several developers already required, we should really use the
> > > > standard -git tree as everybody's else. This will simplify a lot the way we
> > > > work, and give us more agility to send patches upstream.
> > > >
> > > > With this backport script, plus the current v4l-dvb building systems, and after
> > > > having all backport rules properly mapped, we can generate a "test tree"
> > > > based on -git drivers/media, for the users to test the drivers against their
> > > > kernels, and still use a clean tree for development.
> > >
> > > Sorry, switching to git is great, but just to make sure I understood you
> > > right: by "-git drivers/media" you don't mean it is going to be a git tree
> > > of only drivers/media, but it is going to be a normal complete Linux
> > > kernel tree, right?
> >
> > So there will be no way we can test a driver without switching to a new
> > kernel hourly?  And there is no way we can test someone else's tree without
> > compiling an entirely new kernel and rebooting?  And every tree we want to
> > work on requires a complete copy of the entire kernel source?
>
> AFAIR, Mauro wanted to provide snapshots for those who absolutely prefer
> to work with partial trees. Although, to be honest, I don't understand
> what makes video drivers so special. Think about audio drivers, or
> network, including WLAN. I never heard about those subsystems working with
> or providing subtree snapshots. If only before specific drivers or
> subsystems are included in the mainline, but not long after that.

ALSA used a partial tree, but their system was much worse than v4l-dvb's.
I think the reason more systems don't do it is that setting up the build
system we have with v4l-dvb was a lot of work.  They don't have that.

Lots of subsystems are more tightly connected to the kernel and compiling
the subsystem out of tree against any kernel just wouldn't work.  Some
subsystems (like say gpio or led) mostly provide a framework to the rest of
the kernel so working on them without the rest of the tree doesn't make
sense either.  Or they don't get many patches and don't have many active
maintainers so they don't really have any development SCM at all.  Just
some patches through email that get applied by one maintainer.

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Hans Verkuil]

On Thursday 05 March 2009 21:57:16 Trent Piepho wrote:
> On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> > On Thu, 5 Mar 2009, Trent Piepho wrote:
> > > On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> > > > On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote:
> > > > > Beside the fact that we don't need to strip support for legacy
> > > > > kernels, the advantage of using this method is that we can
> > > > > evolute to a new development model. As several developers already
> > > > > required, we should really use the standard -git tree as
> > > > > everybody's else. This will simplify a lot the way we work, and
> > > > > give us more agility to send patches upstream.
> > > > >
> > > > > With this backport script, plus the current v4l-dvb building
> > > > > systems, and after having all backport rules properly mapped, we
> > > > > can generate a "test tree" based on -git drivers/media, for the
> > > > > users to test the drivers against their kernels, and still use a
> > > > > clean tree for development.
> > > >
> > > > Sorry, switching to git is great, but just to make sure I
> > > > understood you right: by "-git drivers/media" you don't mean it is
> > > > going to be a git tree of only drivers/media, but it is going to be
> > > > a normal complete Linux kernel tree, right?
> > >
> > > So there will be no way we can test a driver without switching to a
> > > new kernel hourly?  And there is no way we can test someone else's
> > > tree without compiling an entirely new kernel and rebooting?  And
> > > every tree we want to work on requires a complete copy of the entire
> > > kernel source?
> >
> > AFAIR, Mauro wanted to provide snapshots for those who absolutely
> > prefer to work with partial trees. Although, to be honest, I don't
> > understand what makes video drivers so special. Think about audio
> > drivers, or network, including WLAN. I never heard about those
> > subsystems working with or providing subtree snapshots. If only before
> > specific drivers or subsystems are included in the mainline, but not
> > long after that.
>
> ALSA used a partial tree, but their system was much worse than v4l-dvb's.
> I think the reason more systems don't do it is that setting up the build
> system we have with v4l-dvb was a lot of work.  They don't have that.
>
> Lots of subsystems are more tightly connected to the kernel and compiling
> the subsystem out of tree against any kernel just wouldn't work.  Some
> subsystems (like say gpio or led) mostly provide a framework to the rest
> of the kernel so working on them without the rest of the tree doesn't
> make sense either.  Or they don't get many patches and don't have many
> active maintainers so they don't really have any development SCM at all. 
> Just some patches through email that get applied by one maintainer.

Our model of just the subsystem is fine when all you are dealing with are 
PCI and USB devices, but especially with embedded devices you get a lot of 
links to the platform code. For that you need to have a full kernel.

I expect that the embedded drivers will be a very active area for the next 
several years so we have to make sure we can handle that.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Guennadi Liakhovetski]

On Thu, 5 Mar 2009, Trent Piepho wrote:

> ALSA used a partial tree, but their system was much worse than v4l-dvb's.
> I think the reason more systems don't do it is that setting up the build
> system we have with v4l-dvb was a lot of work.  They don't have that.

Right, it was a lot of work, it is still quite a bit of work (well, I'm 
not doing that work directly, but it affetcs me too, when I have to adjust 
patches, that I generated from a complete kernel tree to fit 
compatibility-"emhanced" versions), and it is not going to be less work.

> Lots of subsystems are more tightly connected to the kernel and compiling
> the subsystem out of tree against any kernel just wouldn't work.  Some
> subsystems (like say gpio or led) mostly provide a framework to the rest of
> the kernel so working on them without the rest of the tree doesn't make
> sense either.  Or they don't get many patches and don't have many active
> maintainers so they don't really have any development SCM at all.  Just
> some patches through email that get applied by one maintainer.

That's why I didn't give LED or GPIO or SPI or I2C or SCSI or ATA or MMC 
or MTD or ... as examples, but audio and network, which are also largely 
"consumer" interfaces and are actively developed.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> On Thu, 5 Mar 2009, Trent Piepho wrote:
> > ALSA used a partial tree, but their system was much worse than v4l-dvb's.
> > I think the reason more systems don't do it is that setting up the build
> > system we have with v4l-dvb was a lot of work.  They don't have that.
>
> Right, it was a lot of work, it is still quite a bit of work (well, I'm
> not doing that work directly, but it affetcs me too, when I have to adjust
> patches, that I generated from a complete kernel tree to fit
> compatibility-"emhanced" versions), and it is not going to be less work.

Why must you generate your patches from a different tree?  One could just
as well say that the linux kernel indentation style is more work, since
they use GNU style have to translate their patch from a re-indented tree.

You could just make your patches in the v4l-dvb tree and then you wouldn't
have the translate them.  In fact it could be easier, as you can develop
your patches against the kernel you are using now instead of needing to
switch to the latest kernel from a few hours ago.

I wish I could use the v4l-dvb system for embedded system development in
other areas.  In my experience most embedded hardware can't run the stock
kernel.  Most embedded system development is for new systems that don't
have all their code in the stock kernel yet.  They often have very device
specific things that aren't even wanted in the kernel.  So you end up
needing to do development with an older kernel that works for your device,
e.g. the kernel that came with the BSP.

In order to submit your patches, you then have to port them to the latest
kernel.  Not only is that extra work, you now have two patches, one in your
device tree and one in your kernel.org tree.  If you fix one patch you have
to manually keep the other in sync.  The v4l-dvb is much better as you can
have just _one_ patch that works on _both_ kernels.

> > Lots of subsystems are more tightly connected to the kernel and compiling
> > the subsystem out of tree against any kernel just wouldn't work.  Some
> > subsystems (like say gpio or led) mostly provide a framework to the rest of
> > the kernel so working on them without the rest of the tree doesn't make
> > sense either.  Or they don't get many patches and don't have many active
> > maintainers so they don't really have any development SCM at all.  Just
> > some patches through email that get applied by one maintainer.
>
> That's why I didn't give LED or GPIO or SPI or I2C or SCSI or ATA or MMC
> or MTD or ... as examples, but audio and network, which are also largely
> "consumer" interfaces and are actively developed.

Audio was out of tree.  If they had a better system, like v4l-dvb does,
they might well still be out of tree.  And aren't there some wireless
packages that are out of tree?

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Guennadi Liakhovetski]

On Fri, 6 Mar 2009, Trent Piepho wrote:

> On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> > On Thu, 5 Mar 2009, Trent Piepho wrote:
> > > ALSA used a partial tree, but their system was much worse than v4l-dvb's.
> > > I think the reason more systems don't do it is that setting up the build
> > > system we have with v4l-dvb was a lot of work.  They don't have that.
> >
> > Right, it was a lot of work, it is still quite a bit of work (well, I'm
> > not doing that work directly, but it affetcs me too, when I have to adjust
> > patches, that I generated from a complete kernel tree to fit
> > compatibility-"emhanced" versions), and it is not going to be less work.
> 
> Why must you generate your patches from a different tree?  One could just
> as well say that the linux kernel indentation style is more work, since
> they use GNU style have to translate their patch from a re-indented tree.

[snip]

Hans has already answered your question very well in this thread. I don't 
think I can add anything.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Re: Results of the 'dropping support for kernels <2.6.22' poll

[hermann pitton]

Hi,

Am Samstag, den 07.03.2009, 01:46 +0100 schrieb Guennadi Liakhovetski:
> On Fri, 6 Mar 2009, Trent Piepho wrote:
> 
> > On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> > > On Thu, 5 Mar 2009, Trent Piepho wrote:
> > > > ALSA used a partial tree, but their system was much worse than v4l-dvb's.
> > > > I think the reason more systems don't do it is that setting up the build
> > > > system we have with v4l-dvb was a lot of work.  They don't have that.
> > >
> > > Right, it was a lot of work, it is still quite a bit of work (well, I'm
> > > not doing that work directly, but it affetcs me too, when I have to adjust
> > > patches, that I generated from a complete kernel tree to fit
> > > compatibility-"emhanced" versions), and it is not going to be less work.
> > 
> > Why must you generate your patches from a different tree?  One could just
> > as well say that the linux kernel indentation style is more work, since
> > they use GNU style have to translate their patch from a re-indented tree.
> 
> [snip]
> 
> Hans has already answered your question very well in this thread. I don't 
> think I can add anything.
> 
> Thanks
> Guennadi

for me Trent clearly has the better arguments, but I do have of course a
different point of view.

Let's have this embedded Linux conference and listen to the arguments we
hopefully get some links to.

There is a lot going on, but you must convince me at least to buy some
of this stuff I call gadgets. I don't see any need so far ;)

You likely can get still anybody seriously interested to build the
always next rc1 and then one close to the final next kernel release too,
but I seriously doubt that you can convince anybody at all to give up
totally what we have for embedded mixed trees fun on latest git and
break all others by will for your latest pleasure.

Cheers,
Hermann

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Adam Baker]

On Saturday 07 March 2009, Trent Piepho wrote:
> Audio was out of tree.  If they had a better system, like v4l-dvb does,
> they might well still be out of tree.  And aren't there some wireless
> packages that are out of tree?

Wireless development is done in tree and then copied to a compat tree that 
contains just the wireless drivers, stack and compatibility stubs. A year or 
two back there were some drivers developed out of tree so they could be 
tested more easily but it became too much of an overhead to work that way.

Adam

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Sat, 7 Mar 2009, Guennadi Liakhovetski wrote:
> On Fri, 6 Mar 2009, Trent Piepho wrote:
> > On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> > > On Thu, 5 Mar 2009, Trent Piepho wrote:
> > > > ALSA used a partial tree, but their system was much worse than v4l-dvb's.
> > > > I think the reason more systems don't do it is that setting up the build
> > > > system we have with v4l-dvb was a lot of work.  They don't have that.
> > >
> > > Right, it was a lot of work, it is still quite a bit of work (well, I'm
> > > not doing that work directly, but it affetcs me too, when I have to adjust
> > > patches, that I generated from a complete kernel tree to fit
> > > compatibility-"emhanced" versions), and it is not going to be less work.
> >
> > Why must you generate your patches from a different tree?  One could just
> > as well say that the linux kernel indentation style is more work, since
> > they use GNU style have to translate their patch from a re-indented tree.
>
> [snip]
>
> Hans has already answered your question very well in this thread. I don't
> think I can add anything.

Because there are patches that touch both the media tree and outside it?  I
don't buy it.  Even for sub-systems that only use full git trees, you
almost never see a patch that touches multiple areas of maintainership.
It's just too hard to deal with getting acks from everyone involved,
dealing with the out-of-sync development git trees of the multiple areas
you want to touch, figuring out who will take your patch, etc.

It seems like the real complaint is that dealing v4l-dvb's development
system is more work for those people who choose not to use it.  Why don't
we just switch to CVS while were at it, to make it easier for those who
don't want to learn git?

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Hans Verkuil]

On Sunday 15 March 2009 17:39:11 Trent Piepho wrote:
> On Sat, 7 Mar 2009, Guennadi Liakhovetski wrote:
> > On Fri, 6 Mar 2009, Trent Piepho wrote:
> > > On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote:
> > > > On Thu, 5 Mar 2009, Trent Piepho wrote:
> > > > > ALSA used a partial tree, but their system was much worse than
> > > > > v4l-dvb's. I think the reason more systems don't do it is that
> > > > > setting up the build system we have with v4l-dvb was a lot of
> > > > > work.  They don't have that.
> > > >
> > > > Right, it was a lot of work, it is still quite a bit of work (well,
> > > > I'm not doing that work directly, but it affetcs me too, when I
> > > > have to adjust patches, that I generated from a complete kernel
> > > > tree to fit compatibility-"emhanced" versions), and it is not going
> > > > to be less work.
> > >
> > > Why must you generate your patches from a different tree?  One could
> > > just as well say that the linux kernel indentation style is more
> > > work, since they use GNU style have to translate their patch from a
> > > re-indented tree.
> >
> > [snip]
> >
> > Hans has already answered your question very well in this thread. I
> > don't think I can add anything.
>
> Because there are patches that touch both the media tree and outside it? 
> I don't buy it.  Even for sub-systems that only use full git trees, you
> almost never see a patch that touches multiple areas of maintainership.
> It's just too hard to deal with getting acks from everyone involved,
> dealing with the out-of-sync development git trees of the multiple areas
> you want to touch, figuring out who will take your patch, etc.

Think embedded devices like omap, davinci and other SoC devices. These all 
require changes in both v4l-dvb and arch at the same time. Easy to do if 
you have a full git tree, much harder to do in the current situation.

These devices will become much more important in the coming months and 
years, so having a proper git tree will definitely help. 

This is a relatively new development and before that it was indeed rare to 
see patches touching on areas outside the media tree. Not anymore, though.

Regards,

	Hans

> It seems like the real complaint is that dealing v4l-dvb's development
> system is more work for those people who choose not to use it.  Why don't
> we just switch to CVS while were at it, to make it easier for those who
> don't want to learn git?


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Devin Heitmueller]

On Sun, Mar 15, 2009 at 12:39 PM, Trent Piepho <xyzzy@speakeasy.org> wrote:
> It seems like the real complaint is that dealing v4l-dvb's development
> system is more work for those people who choose not to use it.  Why don't
> we just switch to CVS while were at it, to make it easier for those who
> don't want to learn git?

Personally, the problem for me is not one of which source control
system we use.  I don't care if it's cvs, svn, bzr, hg, or git.  What
I do care about is what the tree contains.

I do all of my development on a stock Ubuntu box that is running the
latest stable release (Intrepid right now).  I want to do v4l-dvb
development, but I do *not* want to be required to run the bleeding
edge kernel.  I want to do v4l-dvb development without having to worry
about whether my wireless chipset is going to work today, or my video
driver.  Having a stable distro allows me to focus on *my* driver
without being susceptible to breakage unrelated to my work.

I know I'm not the only one who develops with this model.  This is not
just an issue about the people looking to test the tree.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Sun, 15 Mar 2009, Hans Verkuil wrote:
> On Sunday 15 March 2009 17:39:11 Trent Piepho wrote:
> > Because there are patches that touch both the media tree and outside it?
> > I don't buy it.  Even for sub-systems that only use full git trees, you
> > almost never see a patch that touches multiple areas of maintainership.
> > It's just too hard to deal with getting acks from everyone involved,
> > dealing with the out-of-sync development git trees of the multiple areas
> > you want to touch, figuring out who will take your patch, etc.
>
> Think embedded devices like omap, davinci and other SoC devices. These all
> require changes in both v4l-dvb and arch at the same time. Easy to do if
> you have a full git tree, much harder to do in the current situation.
>
> These devices will become much more important in the coming months and
> years, so having a proper git tree will definitely help.
>
> This is a relatively new development and before that it was indeed rare to
> see patches touching on areas outside the media tree. Not anymore, though.

ALSA has a full git tree now, so there should be all these patches that
touch sound/ and something out side of sound too?  I'm not seeing them.
The only patches that touch inside and outside of ALSA are the ones that
fix some misspelled word in 100 random files or rename a linux header file.

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Hans Werner]

> Hans,
> 
> On Mon, 2 Mar 2009 22:18:24 +0100
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> 
> > In the final analysis I'm the boss of my own time. And I've decided that
> > once the conversion of all the i2c modules is finished I'll stop
> spending 
> > time on the compatibility code for kernels <2.6.22 as it is simply no 
> > longer an effective use of my time. If someone else wants to spend time
> on 
> > that, then that's great and I will of course answer questions or help in
> > whatever way is needed.
> > 
> > I know that Mauro thinks he can keep the backwards compat code in by
> doing 
> > nifty code transformations. It would be nice if he succeeds (and I have
> no 
> > doubt that it is possible given enough time and effort), but personally
> I 
> > think it is time better spent elsewhere.
> 
> It required just a couple of hours today, in order to add the I2C
> conversion
> rules on the backport tree:
> 
> 	http://linuxtv.org/hg/~mchehab/backport/
> 
> There, I used, as example, the tea6415c.c file that you sent me, meant to
> be an
> example of a driver converted to use just the new I2C API. I've removed
> from it
> all the other #ifdefs for 2.6.26, so, the module doesn't have any compat
> bits
> (except for "compat.h" that can also be handled by the script). I didn't
> compile
> the entire tree, since several drivers will break, as they aren't ported
> yet
> to the new I2C style.
> 
> Maybe a few adjustments on the backport.pl may be needed, after having all
> drivers converted to 2.6.22, since the final version may need some other
> patching rules.
> 
> That's said, the backport tree is still an experimental work. The scripts
> require more time to be tested, and the Makefiles need some cleanups.

Mauro,

neat, but I still think time spent on backporting work would be better
spent on cutting-edge development. Two hours here ... two hours there
... it all adds up to a significant investment of time.

> Beside the fact that we don't need to strip support for legacy kernels,
> the
> advantage of using this method is that we can evolute to a new development
> model. As several developers already required, we should really use the
> standard -git tree as everybody's else. This will simplify a lot the way
> we
> work, and give us more agility to send patches upstream.

Great! Do you have a plan for how soon a move to the standard git tree
will happen? The sooner the better IMO.

> With this backport script, plus the current v4l-dvb building systems, and
> after
> having all backport rules properly mapped, we can generate a "test tree"
> based on -git drivers/media, for the users to test the drivers against
> their
> kernels, and still use a clean tree for development.
> 
> Cheers,
> Mauro

If I understand correctly you are suggesting that a backporting
system would continue to exist?

Why? Surely this would be a heavy ball-and-chain to drag around for 
eternity. Why not lose the backporting and go for the simplicity and 
agility you mentioned above?

Regards,
Hans W.

-- 
Release early, release often.

Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Mauro Carvalho Chehab]

On Fri, 20 Mar 2009 21:47:07 +0100
"Hans Werner" <HWerner4@gmx.de> wrote:

> > That's said, the backport tree is still an experimental work. The scripts
> > require more time to be tested, and the Makefiles need some cleanups.
> 
> Mauro,
> 
> neat, but I still think time spent on backporting work would be better
> spent on cutting-edge development. Two hours here ... two hours there
> ... it all adds up to a significant investment of time.

True. Yet, the more easy for end users to have their devices working on their
environments, the more number of "end tail" contributions we'll have, fixing
issues on specific devices whose the main developers don't have.

> > Beside the fact that we don't need to strip support for legacy kernels,
> > the
> > advantage of using this method is that we can evolute to a new development
> > model. As several developers already required, we should really use the
> > standard -git tree as everybody's else. This will simplify a lot the way
> > we
> > work, and give us more agility to send patches upstream.
> 
> Great! Do you have a plan for how soon a move to the standard git tree
> will happen? The sooner the better IMO.

Let's first finish 2.6.30 merge window. Then, we'll have more time to cleanup
the tree and think on moving to git. Now, everyone is focused on having their
work done for the next tree.

> If I understand correctly you are suggesting that a backporting
> system would continue to exist?
> 
> Why? Surely this would be a heavy ball-and-chain to drag around for 
> eternity. Why not lose the backporting and go for the simplicity and 
> agility you mentioned above?

My suggestion is to keep a backporting system, but more targeted at the
end-users. The reasons are the ones explained above. Basically:

- Allow end-users to test the drivers without requiring immediate
  kernel upgrade to the latest -rc-git tree, on their environments;
- Offer a tree where people can use to generate contributions like adding
  new devices at cards table.

It should also be clear for all that the backported system is not targeted on
offering any kind of implicit or explicit warranty that a driver will work
on a legacy kernel. It is a paper of the distros to provide such kind of
support. Also, to provide such warranty, other files outside linux/media would
need to be patched [1].
 
So, the backport should keep being provided as a best-effort model, just like
what we have right now with all the backports on our tree: we expect it to
work, but it may not work on some environments. No warranties are given.

I intend to write a proposal about it sometime after the merge window, for
people to comment and to contribute with.

[1] Just as an example, the USB video drivers leak memory if you're using
isoc USB transfers on kernels bellow 2.6.29. So, after some stress conditions,
you can eventually run out of memory on legacy kernels. The fix is outside the
linux media scope (it is due to a bug at ehci_hcd scheduler).

Cheers,
Mauro

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Devin Heitmueller]

On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> My suggestion is to keep a backporting system, but more targeted at the
> end-users. The reasons are the ones explained above. Basically:

Ok, so just so we're all on the same page - we're telling all the
developers not willing to run a bleeding edge rc kernel to screw off?

Got an Nvidia video card?  Go away!
The wireless broken in this week's -rc candidate?  Go away!
Your distro doesn't yet support the bleeding edge kernel?   Go away!
Want to have a stable base on which to work so you can focus on
v4l-dvb development?  Go away!

I can tell you quite definitely that you're going to lose some
developers with this approach.  You better be damn sure that the lives
you're making easier are going to significantly outweigh the
developers willing to contribute who you are casting aside.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Mauro Carvalho Chehab]

On Fri, 20 Mar 2009 22:03:21 -0400
Devin Heitmueller <devin.heitmueller@gmail.com> wrote:

> On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> > My suggestion is to keep a backporting system, but more targeted at the
> > end-users. The reasons are the ones explained above. Basically:
> 
> Ok, so just so we're all on the same page - we're telling all the
> developers not willing to run a bleeding edge rc kernel to screw off?
> 
> Got an Nvidia video card?  Go away!
> The wireless broken in this week's -rc candidate?  Go away!
> Your distro doesn't yet support the bleeding edge kernel?   Go away!
> Want to have a stable base on which to work so you can focus on
> v4l-dvb development?  Go away!
> 
> I can tell you quite definitely that you're going to lose some
> developers with this approach.  You better be damn sure that the lives
> you're making easier are going to significantly outweigh the
> developers willing to contribute who you are casting aside.

Devin,

Please, don't invert the things. 

I am the one that is trying to defend the need of keeping the backport, while
most of you are trying to convince to me to just drop it, since developers will
run the bleeding edge -rc.

With the argument that developers shouldn't run the bleeding edge kernel, I'd
say you should do it. This is the way kernel development is. You shouldn't send
something upstream, if your patch doesn't run with the latest -rc. In my case,
I have my alpha environment for such tests, separated from the environment I
write my code. This allows me to do development on a more stable environment,
being sure that it will keep running with the latest kernel.

With the respect of using the backported environment for developing, you can do
it, if you want. It will be available for all usages. Have you ever seen the
approach I'm proposing at my backported tree? I can't see why you couldn't use
it for development also.


Cheers,
Mauro

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Fri, 20 Mar 2009, Devin Heitmueller wrote:
> On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> > My suggestion is to keep a backporting system, but more targeted at the
> > end-users. The reasons are the ones explained above. Basically:
>
> Ok, so just so we're all on the same page - we're telling all the
> developers not willing to run a bleeding edge rc kernel to screw off?
>
> Got an Nvidia video card?  Go away!
> The wireless broken in this week's -rc candidate?  Go away!
> Your distro doesn't yet support the bleeding edge kernel?   Go away!
> Want to have a stable base on which to work so you can focus on
> v4l-dvb development?  Go away!

Maybe you're supposed to have ten computers running different kernels?

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Sat, 21 Mar 2009, Mauro Carvalho Chehab wrote:
> On Fri, 20 Mar 2009 22:03:21 -0400
> Devin Heitmueller <devin.heitmueller@gmail.com> wrote:
>
> > On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab
> > <mchehab@infradead.org> wrote:
> > > My suggestion is to keep a backporting system, but more targeted at the
> > > end-users. The reasons are the ones explained above. Basically:
> >
> > Ok, so just so we're all on the same page - we're telling all the
> > developers not willing to run a bleeding edge rc kernel to screw off?
> >
> > Got an Nvidia video card?  Go away!
> > The wireless broken in this week's -rc candidate?  Go away!
> > Your distro doesn't yet support the bleeding edge kernel?   Go away!
> > Want to have a stable base on which to work so you can focus on
> > v4l-dvb development?  Go away!
> >
> > I can tell you quite definitely that you're going to lose some
> > developers with this approach.  You better be damn sure that the lives
> > you're making easier are going to significantly outweigh the
> > developers willing to contribute who you are casting aside.
>
> Devin,
>
> Please, don't invert the things.
>
> I am the one that is trying to defend the need of keeping the backport, while
> most of you are trying to convince to me to just drop it, since developers will
> run the bleeding edge -rc.

I don't run bleeding edge rc.  I have one computer.  I need it to work.  I
like to go months without rebooting.

> With the argument that developers shouldn't run the bleeding edge kernel, I'd
> say you should do it. This is the way kernel development is. You shouldn't send
> something upstream, if your patch doesn't run with the latest -rc. In my case,

Isn't developer time better spent working on drivers that the developer has
knownedlge of instead of compiling kernels, rebooting, updating nvidia
drivers, etc?

> I have my alpha environment for such tests, separated from the environment I
> write my code. This allows me to do development on a more stable environment,
> being sure that it will keep running with the latest kernel.

You must have multiple computers then.  Not of all us do.  Or have space.
Or want to use the energy to run them.

> With the respect of using the backported environment for developing, you can do
> it, if you want. It will be available for all usages. Have you ever seen the
> approach I'm proposing at my backported tree? I can't see why you couldn't use
> it for development also.

Because you'll have to port the patches to the git tree.

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Devin Heitmueller]

On Fri, Mar 20, 2009 at 11:04 PM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> Devin,
>
> Please, don't invert the things.
>
> I am the one that is trying to defend the need of keeping the backport, while
> most of you are trying to convince to me to just drop it, since developers will
> run the bleeding edge -rc.
>
> With the argument that developers shouldn't run the bleeding edge kernel, I'd
> say you should do it. This is the way kernel development is. You shouldn't send
> something upstream, if your patch doesn't run with the latest -rc. In my case,
> I have my alpha environment for such tests, separated from the environment I
> write my code. This allows me to do development on a more stable environment,
> being sure that it will keep running with the latest kernel.
>
> With the respect of using the backported environment for developing, you can do
> it, if you want. It will be available for all usages. Have you ever seen the
> approach I'm proposing at my backported tree? I can't see why you couldn't use
> it for development also.

Mauro,

When this thread was started, it was about dropping support for
kernels < 2.6.22.  However, it has turned into a thread about moving
to git and dropping support for *all* kernels less than the bleeding
edge -rc candidate (only supporting them through a backport system for
testers).  The two are very different things.

I agree with the general consensus that we should raise the "minimum
bar" from 2.6.16 to 2.6.22.  And I also believe that we need to ensure
that we do not want to lose testers by requiring them to run the
latest kernel release.  However, now we are talking about what the
*developers* are expected to run.  What has now been proposed is
changing the build system such that developers must run the latest -rc
kernel, which I do not believe is a good idea.  It makes it easier for
the maintainer to merge patches, however at the cost of the other
developers trying to focus on v4l-dvb development without having to
worry about whether this week's -rc kernel is going to work in their
environment.

It already takes me half an hour to checkout and build the latest
v4l-dvb tree.  Telling me that now I'm going to have to download and
build the entire kernel on a weekly basis, as well as deal with
whatever crap gets broken in my environment, is too much for many
developers who don't work for a distribution vendor.  For a developer
working nights and weekends on this stuff, this ends up being a
significant fraction of my development time.

I just want it to be clear that there are developers who are not
willing to run the latest -rc kernel just for the luxury of being able
to contribute to v4l-dvb.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Mauro Carvalho Chehab]

On Sat, 21 Mar 2009 08:05:51 -0400
Devin Heitmueller <devin.heitmueller@gmail.com> wrote:

> On Fri, Mar 20, 2009 at 11:04 PM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> > Devin,
> >
> > Please, don't invert the things.
> >
> > I am the one that is trying to defend the need of keeping the backport, while
> > most of you are trying to convince to me to just drop it, since developers will
> > run the bleeding edge -rc.
> >
> > With the argument that developers shouldn't run the bleeding edge kernel, I'd
> > say you should do it. This is the way kernel development is. You shouldn't send
> > something upstream, if your patch doesn't run with the latest -rc. In my case,
> > I have my alpha environment for such tests, separated from the environment I
> > write my code. This allows me to do development on a more stable environment,
> > being sure that it will keep running with the latest kernel.
> >
> > With the respect of using the backported environment for developing, you can do
> > it, if you want. It will be available for all usages. Have you ever seen the
> > approach I'm proposing at my backported tree? I can't see why you couldn't use
> > it for development also.
> 
> Mauro,
> 
> When this thread was started, it was about dropping support for
> kernels < 2.6.22.  However, it has turned into a thread about moving
> to git and dropping support for *all* kernels less than the bleeding
> edge -rc candidate (only supporting them through a backport system for
> testers).  The two are very different things.

> 
> I agree with the general consensus that we should raise the "minimum
> bar" from 2.6.16 to 2.6.22.  And I also believe that we need to ensure
> that we do not want to lose testers by requiring them to run the
> latest kernel release.  However, now we are talking about what the
> *developers* are expected to run.  What has now been proposed is
> changing the build system such that developers must run the latest -rc
> kernel, which I do not believe is a good idea.  It makes it easier for
> the maintainer to merge patches, however at the cost of the other
> developers trying to focus on v4l-dvb development without having to
> worry about whether this week's -rc kernel is going to work in their
> environment.
> 

As I said before, this is not the proper moment for such discussions. People
are still focused on the 2.6.30 merge stuff. We should discuss it by the end of
the merge window, discussing the newly model to be used starting at the 2.6.31 cycle.

It is important to discuss a new model, since the current one has some flaws,
like:
- bug fixes are sometimes postponed, since they depend on the bleeding edge
patches;
- our model is different from the rest of Linux kernel community;
- it is hard to merge patches that needs coordination with changes outside
drivers/media;
- the need of conversion for each -hg patch into -git;
- the need of backport upstream changes at the building system, and keeping
track of such changes.
- the increased volume of patches on v4l/dvb made our development model
incredible complex for submitting work upstream, since it doesn't scale well,
and has caused some hard to solve merge conflicts.

>From my side, I never proposed to drop the backport system, but to improve it,
in a way that people can keep working and testing the subsystem with legacy
kernels, although I've seen several comments on this poll where people are
arguing to just drop all backports.

> It already takes me half an hour to checkout and build the latest
> v4l-dvb tree.  Telling me that now I'm going to have to download and
> build the entire kernel on a weekly basis, as well as deal with
> whatever crap gets broken in my environment, is too much for many
> developers who don't work for a distribution vendor.  For a developer
> working nights and weekends on this stuff, this ends up being a
> significant fraction of my development time.

It seems that you're afraid of the unknown. There are several ways to use -git.
You can even use a spare git clone, where, for example, only drivers/media will
be cloned on your local machine. 

Since we haven't discussed how a new development model would work, it is
pointless to be against something that were not even proposed. And it weren't
proposed yet due to the fact that people didn't have time yet to prepare a
proposal and test it.

Also, due to the need of providing fix packages for linux-next, the current
development kernel and the last stable one, this means that any model we use
will need to work properly on all those cases.

> I just want it to be clear that there are developers who are not
> willing to run the latest -rc kernel just for the luxury of being able
> to contribute to v4l-dvb.

If we review the poll comments, and include some occasional emails about our
development model, we'll have all sorts of different opinions:
- People that want to keep backports as-is;
- People that want to set the baseline to 2.6.22;
- People that want to set a higher line (some even proposed to cut it to support
  just the latest kernel);
- People that want to have a lower baseline (to support embedded, for example);
- People that just want us to use a clone of Linus -git tree;
- People that acked with the poll, without giving any additional comments.

You'll see developers and end users on all the above categories.

My conclusion about the poll is that, whatever development model we choose
(even keeping the current one), some people will be unhappy.

So, instead of just complaining, people should come with bright proposals about
a model that will better fit to our needs.

Cheers,
Mauro

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Trent Piepho]

On Sat, 21 Mar 2009, Mauro Carvalho Chehab wrote:
> > When this thread was started, it was about dropping support for
> > kernels < 2.6.22.  However, it has turned into a thread about moving
> > to git and dropping support for *all* kernels less than the bleeding
> > edge -rc candidate (only supporting them through a backport system for
> > testers).  The two are very different things.

Yes they are very different things.  I do not like a poll about dropping
the current build system being disguised as a poll about dropping support
for very old kernels.  How about a new poll, "should developers be required
to have multiple systems and spend the majority of their time recompiling
new kernels and testing nvidia and wireless drivers?"

> It is important to discuss a new model, since the current one has some flaws,
> like:

These are problems caused by having a large project with multiple areas of
maintainership and many developers working simulaniously.  Switching to a
full kernel tree and dropping cross kernel building support isn't going to
a help.

> - bug fixes are sometimes postponed, since they depend on the bleeding edge
> patches;

Full kernel source will just make this worse!  Your v4l patch needs some
very recent change to pci core?  With a full tree, the v4l-dvb maintainer
will have to wait until the pci maintainer accepts the patch and puts it
into his tree.  Then the v4l-dvb maintainer will have to pull the pci tree.
That won't just give you the one patch you need, but 100 other patches in
the tree.  Then and only then can any v4l-dvb devlopers work on their patch
that needs the pci fix.

With the current system a v4l-dvb devloper can pick just the pci patch he
needs and put it into his kernel or he can get the pci tree.  Then he's
free to develop a v4l-dvb patch that needs the pci patch.  He can probably
even do his v4l-dvb patch in a compatible manner, so that it can go in the
v4l-dvb tree before the pci patch has even appeared in the pci tree.

> - our model is different from the rest of Linux kernel community;

Their model is worse.  Why make things worse just to help people who choose
not to learn new things?

> - it is hard to merge patches that needs coordination with changes outside
> drivers/media;

It's hard to merge patches that touch multiple areas of maintainership even
if everyone uses full trees.

> - the need of conversion for each -hg patch into -git;

It's done by an automated script.  It allows fixing the large number of
mistakes commited to the v4l-dvb tree.

> - the need of backport upstream changes at the building system, and keeping
> track of such changes.

You will still have patches that touch drivers/media that don't go in via
the v4l-dvb tree.  Just look at any system with a full tree, you'll see
commits that touch that system's files and went in as some system wide
cleanup patch via another maintainer's tree.  So you'll still have to merge
these patches.

> - the increased volume of patches on v4l/dvb made our development model
> incredible complex for submitting work upstream, since it doesn't scale well,
> and has caused some hard to solve merge conflicts.

More patches means more merge conflicts.  Why does have an out of tree
build system have anything to do with it?

> You can even use a spare git clone, where, for example, only drivers/media will
> be cloned on your local machine.

Which is useless.  You can't build or run drivers/media only kernel tree!

Re: Results of the 'dropping support for kernels <2.6.22' poll

[Hans Verkuil]

> On Sat, 21 Mar 2009, Mauro Carvalho Chehab wrote:
>> > When this thread was started, it was about dropping support for
>> > kernels < 2.6.22.  However, it has turned into a thread about moving
>> > to git and dropping support for *all* kernels less than the bleeding
>> > edge -rc candidate (only supporting them through a backport system for
>> > testers).  The two are very different things.
>
> Yes they are very different things.  I do not like a poll about dropping
> the current build system being disguised as a poll about dropping support
> for very old kernels.  How about a new poll, "should developers be
> required
> to have multiple systems and spend the majority of their time recompiling
> new kernels and testing nvidia and wireless drivers?"

The poll was just about dropping support for old kernels. Nothing more,
nothing less. There were a few who commented that they wouldn't mind
dropping all compatibility, but those were very much a minority. I for one
want to keep the compatibility code in one way or another so we can
support the last X kernels and make life easy for ourselves and for our
users.

Regards,

       Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG