linux-kernel - Re: A proposal; making 2.6.20 a bugfix only version.

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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 11 Nov 2006 14:15:51 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	Valdis.Kletnieks@...edu
Cc:	Stephen Hemminger <shemminger@...l.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Jesper Juhl <jesper.juhl@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: A proposal; making 2.6.20 a bugfix only version.

Valdis.Kletnieks@...edu wrote:
> On Sat, 11 Nov 2006 07:15:49 +0300, Al Boldi said:
> > I don't think there is a lack of heuristics, nor is there a lack of
> > discussion.  What is needed, is a realization of the problem.
> >
> > IOW, respective tree-owners need to come to a realization of the state
> > of their trees, problem or not.  If it has a problem, that problem needs
> > to be fixed or backed out of stable and moved into dev.
>
> I keep trying to parse this, and it keeps coming up as "content-free".

Think denial.

> For starters, you don't even have a useful definition of "has a problem".
> There's a whole *range* of definitions for that, and even skilled and
> respected members of the Linux kernel community can disagree about whether
> something is "a problem".  For example, see the thread about a week ago
> about "Remove hotplug cpu crap from cpufreq".
>
> If, given a *specific* feature with high wart quotient, we can't agree on
> whether it needs to be fixed or backed out, we're doomed to fail if we
> start handwaving about problems "in general".  As a group, we suck at
> anything that isn't specific, like "Algorithm A is better than B for
> case XYZ".

We don't need to agree whether A is better than B, the mere fact that we 
acknowledge the problem is the first step in finding a solution.

So, either fix it, or back out.

OTOH, if there is no problem, then I guess we have blue skies...


Thanks!

--
Al

-
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/