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
On Fri, Mar 20, 2009 at 11:04 PM, Mauro Carvalho Chehab
mche...@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
On Sat, 21 Mar 2009 08:05:51 -0400
Devin Heitmueller devin.heitmuel...@gmail.com wrote:
On Fri, Mar 20, 2009 at 11:04 PM, Mauro Carvalho Chehab
mche...@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,
Hans,
On Mon, 2 Mar 2009 22:18:24 +0100
Hans Verkuil hverk...@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
On Fri, 20 Mar 2009 21:47:07 +0100
Hans Werner hwern...@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
On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab
mche...@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
On Fri, 20 Mar 2009 22:03:21 -0400
Devin Heitmueller devin.heitmuel...@gmail.com wrote:
On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
My suggestion is to keep a backporting system, but more targeted at the
end-users. The reasons are the ones explained
On Fri, 20 Mar 2009, Devin Heitmueller wrote:
On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab
mche...@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 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
On Sun, Mar 15, 2009 at 12:39 PM, Trent Piepho xy...@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
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
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
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
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.
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
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
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
Hans,
On Mon, 2 Mar 2009 22:18:24 +0100
Hans Verkuil hverk...@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
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
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
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
kilg...@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
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
23 matches
Mail list logo
