linux-kernel - Re: Would it help to encourage users to read/test stable-review patches

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4A9AB45B.6060500@imap.cc>
Date:	Sun, 30 Aug 2009 19:18:19 +0200
From:	Tilman Schmidt <tilman@...p.cc>
To:	"Luis R. Rodriguez" <mcgrof@...il.com>
CC:	stable-review@...nel.org, linux-kernel@...r.kernel.org,
	Greg KH <greg@...ah.com>, Chris Wright <chrisw@...s-sol.org>
Subject: Re: Would it help to encourage users to read/test stable-review patches

Luis R. Rodriguez schrieb:
> We get development review eyes on stable patches during submission
> into a subsystem, and perhaps 1-2 user tests then. Typically patches
> are pretty easy to review for stable submission but I'm wondering
> about cases where things are not so clear [...]
> Do we want more user exposure to stable-review mailing list or is just
> a few developer eyes enough?

Having been bitten quite recently by a -stable mismerge, I am of two
minds about this. On one hand, it would have been nice to catch that
problem during stable review instead of when it hit an actual
distribution. (Ubuntu, as it happened.) On the other hand, I'm not
sure user exposure would have helped all that much in this case.

Generally speaking, the way I understand stable rules, those cases
where things are not so clear shouldn't make it into the review in
the first place. The problem is with the cases where things appear
to be quite clear but aren't. Those are the ones the review cycle
must catch.

Jm2c
T.

-- 
Tilman Schmidt                    E-Mail: tilman@...p.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

Download attachment "signature.asc" of type "application/pgp-signature" (255 bytes)