lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 27 Oct 2009 09:34:28 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	david@...g.hm
CC:	Greg KH <gregkh@...e.de>,
	"John W. Linville" <linville@...driver.com>,
	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] strip: move driver to staging

david@...g.hm wrote:
> On Mon, 26 Oct 2009, Greg KH wrote:
>> A person "claiming maintainership" would then be responsible for keeping
>> the API up to date and ensuring that the driver worked.  To do that,
>> hardware would probably need to be present.
> 
> actually, I understood that the person changing the API was responsible
> for making the changes. when did this change?

I'm not sure what the procedure with drivers/staging/ is, which is a
middle ground between in-tree and out-of-tree.  For in-tree code, last
time I watched the procedure was thus:
  - Those who change an infrastructure are responsible to /code/ the
necessary changes in all infrastructure using subsystems.
  - Usually they are also responsible to submit those changes upstream;
if the change is done in a source-compatible manner during a transition
period, then those API changes in dependent subsystems are sometimes
submitted via the respective subsystem maintainers instead, but that's
not typical.
  - Those who introduce such changes usually cannot be expected to
runtime-test except with one or few subsystems for which they happen to
have matching hardware.  Thus, a small but real danger of regressions
remains.  Usually only the subsystem maintainer or users can detect and
fix such regressions.

But remember, there are no formal rules, there are only "best
practices".  (And sometimes new procedures are tried out in order to
find out whether they work or not, such as the 2.4+2.5 -> 2.6 switch of
development models, the merge window, linux-next, drivers/staging/ as a
way in for out-of-tree drivers, drivers/staging as a way out for broken
or obsolete drivers...)
-- 
Stefan Richter
-=====-==--= =-=- ==-==
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists