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]
Message-Id: <200808271722.55627.mb@bu3sch.de>
Date:	Wed, 27 Aug 2008 17:22:55 +0200
From:	Michael Buesch <mb@...sch.de>
To:	"Tomas Winkler" <tomasw@...il.com>
Cc:	"Johannes Berg" <johannes@...solutions.net>,
	"Marcel Holtmann" <holtmann@...ux.intel.com>,
	"David Miller" <davem@...emloft.net>, linville@...driver.com,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: pull request: wireless-2.6 2008-08-26

On Wednesday 27 August 2008 16:55:15 Tomas Winkler wrote:
> I'm not sure what you are taking about, we did post patches to
> wireless-testing, the driver for 5000 HW  is working in 2.6.27-rc4 I
> personally use it every day.  I'm sending bug fixes, like this seris
> of patches is direct answer to bugs that were discovered very
> recently, I'm not sure what's everybody problem here.

The problem is that these patches are posted in huge batches.
There are three problems (probably more) with that:
1) "Oh, one of these 15 patches recently merged broke my hw"
   instead of
   "This patch XXX recently merged broke my hw"
2) It's a _lot_ harder to review. I do not have the time to review
   a lot of patches at once. I bet other people won't either.
3) If somebody has any objections against one patch, you'll probably
   have to rebase them all (See recent pull request vs cleanups).
   That's additional work for you.

What's the problem with sending patches upstream as soon as you finished
them, instead of piling them up locally and sending them alltogether?

> We fixed bugs in wireless-testing/mac80211 that were there for months
> just because we are only one that do any comprehensive validation. I
> don't  want insult anyone and I really exaggeration here but
> sometimes I have feeling that more people are breaking the code.

If you work directly upstream, you will discover these bugs even faster.
If you maintain your local fork of mac80211, you will have a delay. But
you will have to handle them _anyway_. It's just delayed.

And please, don't act like you don't add bugs to mac80211. There were several
bugs that broke connections on b43 (and probably other hw, too) in the past.

-- 
Greetings Michael.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ