From: "Tomas Winkler" <tomasw@gmail.com>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: "Marcel Holtmann" <holtmann@linux.intel.com>,
"David Miller" <davem@davemloft.net>,
linville@tuxdriver.com, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: pull request: wireless-2.6 2008-08-26
Date: Wed, 27 Aug 2008 14:34:28 +0300 [thread overview]
Message-ID: <1ba2fa240808270434y1589761xd2ff0a48c2e99033@mail.gmail.com> (raw)
In-Reply-To: <1219831828.3891.3.camel@johannes.berg>
On Wed, Aug 27, 2008 at 1:10 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2008-08-27 at 13:05 +0300, Tomas Winkler wrote:
>
>> There is a central problem here, since I cannot really adjust driver
>> development progress from obvious reason with Linux merging window.
>> Upstream kernel is unfortunately not the only customer I report to. So
>> actually stable versions got half backed drivers depending on some
>> arbitrary time cut from my (selfish) development point of view.
>
> FWIW, many people including myself think you should work the other way
> around, that is develop things in the mainline/wireless-testing tree
> rather than developing a stable version internally
> big pile of patches whenever it's convenient for you.
We put big pile once the driver was functional and nobody expected it
to be merged into stable kernel from that point
we post everything that is mergable. The patches are sent out each
Friday after they got through internal review there is nothing, there
is nothing magical about it.
IOW, we think you
> should use Linux upstream as your development tree and then branch off
> of that for the internal stabilisation trees you need for other
> customers, rather than having some sort of internal development tree and
> branching out Linux upstream as you appear to work.
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.
> That would also avoid the nasty surprises you've gotten a few times
> where other people managed to get patches to iwlwifi drivers into the
> Linux tree without you noticing.
I've noticed just deferred to fixing it.
In summary
This was my first Linux project, it was first project that was done on
new HW (nobody could test it but us) and I don't deny I did a lot of
mistake in development process I don't deny that and we are learning
from them.
Tomas
next prev parent reply other threads:[~2008-08-27 11:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 1:30 John W. Linville
2008-08-27 7:38 ` Tomas Winkler
2008-08-27 8:40 ` David Miller
2008-08-27 9:13 ` Tomas Winkler
2008-08-27 11:10 ` Marcel Holtmann
2008-08-27 10:05 ` Tomas Winkler
2008-08-27 10:10 ` Johannes Berg
2008-08-27 10:33 ` David Miller
2008-08-27 11:34 ` Tomas Winkler [this message]
2008-08-27 11:45 ` David Miller
2008-08-27 12:26 ` Tomas Winkler
2008-08-27 13:10 ` Michael Buesch
2008-08-27 14:55 ` Tomas Winkler
2008-08-27 15:22 ` Michael Buesch
2008-08-27 15:45 ` Tomas Winkler
2008-08-27 10:32 ` David Miller
2008-08-27 11:42 ` Tomas Winkler
2008-08-27 13:57 ` Arjan van de Ven
2008-08-27 11:39 ` David Miller
2008-08-27 19:26 ` Tomas Winkler
2008-08-27 20:25 ` Michael Buesch
2008-08-27 23:11 ` Tomas Winkler
2008-08-27 23:31 ` Luis R. Rodriguez
2008-08-28 0:19 ` Tomas Winkler
2008-08-28 1:30 ` Luis R. Rodriguez
2008-08-28 7:59 ` Tomas Winkler
2008-08-28 10:35 ` Bruno Randolf
2008-08-28 10:52 ` Tomas Winkler
2008-08-28 11:13 ` Bruno Randolf
2008-08-28 8:31 ` Michael Buesch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ba2fa240808270434y1589761xd2ff0a48c2e99033@mail.gmail.com \
--to=tomasw@gmail.com \
--cc=davem@davemloft.net \
--cc=holtmann@linux.intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®