linux-kernel - Re: pull request: wireless-2.6 2008-08-26

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]

Message-Id: <20080827.044551.102233262.davem@davemloft.net>
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/