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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 27 Aug 2008 04:45:51 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	tomasw@...il.com
Cc:	johannes@...solutions.net, holtmann@...ux.intel.com,
	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

From: "Tomas Winkler" <tomasw@...il.com>
Date: Wed, 27 Aug 2008 14:34:28 +0300

> Unfortunately fixing bugs on stable branch take precedence  of
> adjusting to new API on development branch that someone decided to do.
>  I wanted to work directly on wireless testing but it was broken over
> an over and I have only limited resources more in testing then in
> development I just had to branch out to be ready with the driver when
> HW is out. People just check the immediate impact of they fix the
> don't test for collateral damage and this is understandable an
> individual developer doesn't have lab with IBSS, BSS, AP, etc setups.

But think about this from the other perspective.

When you queue up tons of things, especially in infrastructure level
code such as mac80211, and on top of it you do your work on the stable
branch and do not do you work against the development tree, guess what
happens?

You show up with accumulated piles of non-trivial patches for people
to review.  And then you'll get upset when they suggest that things be
implemented differently.

It's all because of the gap in time.

And during this time, if you had submitted earlier, you would end up
doing smaller and mode gradual modifications to your design.  And
you'd take care of them before they effect subsequent pieces of work
you want to do which depend upon the earlier bits.

The longer you queue stuff up, the more painful having to change stuff
at the beginning of that queue becomes.  It can invalidate everything
else you worked on.

The only sane way to operate is to post your work early and often, or
else you'll live in a world of hurt, and it will be nobody's fault but
your own.

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