From: Jean Delvare <khali@linux-fr.org>
To: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
Cc: Linus Torvalds <torvalds@osdl.org>,
LKML <linux-kernel@vger.kernel.org>,
LM Sensors <lm-sensors@lm-sensors.org>,
Andrew Morton <akpm@osdl.org>, Greg KH <gregkh@suse.de>
Subject: Re: Incorrect v4l patch in 2.6.15-rc4-git1
Date: Sat, 3 Dec 2005 12:47:15 +0100 [thread overview]
Message-ID: <20051203124715.52f8d736.khali@linux-fr.org> (raw)
In-Reply-To: <1133602035.6724.5.camel@localhost>
Hi Mauro
> Em Sex, 2005-12-02 às 19:28 +0100, Jean Delvare escreveu:
> > Hi Linus,
> >
> > Please revert this commit:
> >
> > author Mauro Carvalho Chehab <mchehab@brturbo.com.br>
> > Thu, 1 Dec 2005 08:51:35 +0000 (00:51 -0800)
> > committer Linus Torvalds <torvalds@g5.osdl.org>
> > Thu, 1 Dec 2005 23:48:57 +0000 (15:48 -0800)
> > commit 769e24382dd47434dfda681f360868c4acd8b6e2
> > tree 1be728dd2f1a7f523e3de5f3f39b97a4b9905dbe
> > parent 6f502b8a7858ecfa7d2a0762f7663b8b3d0808fc
> >
> > [PATCH] V4L: Some funcions now static and I2C hw code for IR
> >
> > - Some funcions are now declared as static
> > - Added a I2C code for InfraRed.
>
> Please point what is so deadly broken on this trivial patch that fix a
> bug where a prodution driver is using I2C code reserved for
> experimentation.
I never said it was deadly broken, just that it wasn't correct (fact)
and probably shouldn't have been accepted at this point of the release
cycle (opinion).
Using an experimental ID is certainly bad and fixing it is welcome, but
this isn't causing any immediate bug as far as I can see. You don't even
use the ID anywhere at the moment.
My point is that defining a new ID just before 2.6.15 when we know
we'll change it right after 2.6.15 is a bad engineering practice. More
importantly, I am asking what the point is of publishing patches for
review before they get integrated if they'll be integrated regardless
of objections. If we can't deal with that kind of situation, our
development process probably needs to be improved - even if in this
one case the harm done is admittedly neglectable.
I'll go undefine these experimental IDs soon anyway, as the concept is
broken IMHO. If driver authors don't use the ID, they can set it to 0.
If they do use it, they better register it soon so as to avoid
collisions with other drivers which haven't been merged either.
Thanks,
--
Jean Delvare
next prev parent reply other threads:[~2005-12-03 11:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-02 18:28 Incorrect v4l patch in 2.6.15-rc4-git1 Jean Delvare
2005-12-03 9:27 ` Mauro Carvalho Chehab
2005-12-03 11:47 ` Jean Delvare [this message]
2005-12-03 18:56 ` Mauro Carvalho Chehab
2005-12-04 23:59 ` Johannes Stezenbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051203124715.52f8d736.khali@linux-fr.org \
--to=khali@linux-fr.org \
--cc=akpm@osdl.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=mchehab@brturbo.com.br \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox