pull request: wireless-next-2.6 2009-10-28

pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

Dave,

I let my patches pile-up!  Yikes!!

This request includes the usual ton of stuff for -next -- driver
updates, fixes for some earlier -next stuff, a few cfg80211 changes to
accomodate the libertas driver, etc.  Of note is the rt2800pci support
added to the rt2x00 family.

Pleaset let me know if there are problems!

Thanks,

John

---

Individual patches are available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/

---

The following changes since commit b37b62fea1d1bf68ca51818f8eb1035188efd030:
  Ben Hutchings (1):
        sfc: Rename 'xfp' file and functions to reflect reality

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master

Abhijeet Kolekar (5):
      iwlwifi/iwl3945: unify rts_tx_cmd_flag
      iwl3945: rename tx to tx_cmd
      iwlwifi/iwl3945: remove data_retry_limit
      iwl3945: rearrange the code.
      iwl3945: disable all tx fifos

Amitkumar Karwar (1):
      libertas: Check return status of command functions

Ben M Cahill (8):
      iwl3945: update iwl3945_apm_init()
      iwlwifi: turn off device when not used.
      iwl3945: remove unnecessary call to apm_ops.reset()
      iwlagn, iwl3945: remove apm_reset() functions
      iwl3945: streamline iwl3945_rfkill_poll()
      iwl3945: move iwl_power_initialize()
      iwlwifi: consolidate apm_init() functions
      iwlwifi: make sure device is reset when unloading driver

Benoit PAPILLAULT (1):
      zd1211rw: Fix TX status reporting in order to have proper rate control

Bob Copeland (1):
      ath5k: use noise calibration from madwifi hal

Christian Lamparter (3):
      ar9170: atomic pending A-MPDU counter
      ar9170usb: atomic pending urbs counter
      ar9170: don't filter BlockACK frames

David Kilroy (1):
      orinoco: use cfg80211 ethtool ops

David-John Willis (1):
      wl1251: add support for PG11 chips.

Holger Schurig (22):
      cfg80211: no cookies in cfg80211_send_XXX()
      cfg80211: remove warning in deauth case
      libertas: make __lbs_cmd_async() non-static
      libertas: cleanup host.h and hostcmd.h
      libertas: harmonize cmd.h
      libertas: make lbs_get_channel() static
      libertas: remove unused lbs_cmd_802_11_inactivity_timeout()
      libertas: remove unused 11d code
      libertas: remove unused 11d.h as well, priv->countryinfo
      libertas: change IW_ESSID_MAX_SIZE -> IEEE80211_MAX_SSID_LEN
      libertas: move scan/assoc related stuff
      libertas: sort variables in struct lbs_private
      libertas: get current channel out of priv->curbssparams
      libertas: move association related commands into assoc.c
      libertas: move lbs_send_iwevcustom_event() to wext.c
      libertas: remove handling for CMD_802_11_LED_GPIO_CTRL
      libertas: remove handling for CMD_GET_TSF
      libertas: remove "struct cmd_ds_gen"
      libertas: move SIOCGIWAP calls to wext.c
      libertas: move mic failure event to wext.c
      libertas: sort and categorize entries in decl.h
      libertas: remove some references to IW_MODE_abc

Ivo van Doorn (2):
      rt2x00: Add rt2x00soc bus module
      rt2x00: Implement support for rt2800pci

Javier Cardona (1):
      mac80211: Learn about mesh portals from multicast traffic

Jay Sternberg (1):
      iwlwifi: add missing commands to syslog messages

John W. Linville (3):
      mac80211: replace netif_tx_{start,stop,wake}_all_queues
      b43: use ieee80211_rx_ni()
      wl1251: re-disable PG10 chips

Juuso Oikarinen (44):
      wl1271: Correction to TX block allocation calculation
      wl1271: Security sequence number handling for TX (for WPA)
      wl1271: Correct TKIP header space handling in TX path
      wl1271: Implement delayed entry into ELP
      wl1271: mask aid bits 14 and 15 in ps-poll template
      wl1271: Implementation for SPI busy word checking
      wl1271: Configure rate policies based on AP rates
      wl1271: Update join usage
      wl1271: Corrections to TX path
      wl1271: use workqueue provided by mac80211 instead of the default
      wl1271: Clear probe-request template after scan
      wl1271: Multicast filtering configuration
      wl1271: Use vmalloc to allocate memory for firmware
      wl1271: Add connection monitoring configuration
      wl1271: Enable beacon filtering with the stack
      wl1271: Configure beacon filtering on if PSM used
      wl1271: Mask unneeded events from firmware to conserve power
      wl1271: Update memory mapping for firmware revision 6.1.0.0.241
      wl1271: Remove RX workaround
      wl1271: Add top-register access functions
      wl1271: RefClk configuration
      wl1271: Update interrupt handling by removing an extra SPI read
      wl1271: Enable ELP
      wl1271: Enable smart reflex
      wl1271: Update TX path block calucation algo
      wl1271: Remove outdated SPI functions
      wl1271: Update boot time configuration for the new firmware
      wl1271: Workaround for reference clock setting on boot.
      wl1271: Add structure for firmware configuration values
      wl1271: Add config structure for RX path parameters
      wl1271: Add config structure for TX path parameters
      wl1271: Add config structure for connection management parameters
      wl1271: Add config structure for FW init parameters
      wl1271: Move default FW config struct away from stack
      wl1271: Fix IRQ enable handling on FW init failure
      wl1271: Implement beacon early termination support
      wl1271: Remove busy-word checking
      wl1271: Fix multicast list handling
      wl1271: Fix event handling mechanism
      wl1271: Support for IPv4 ARP filtering
      wl1271: Remove unnecessary rx_descriptor memory allocation
      wl1271: Correct memory handling for FW boot
      wl1271: Fix filter configuration
      wl1271: Set IEEE80211_FCTL_TODS in the null data template

Kalle Valo (3):
      wl1251: rename spi device to wl1251
      mac80211: add ieee80211_rx_ni()
      wl1251: use ieee80211_rx_ni()

Luciano Coelho (15):
      wl1271: remove unecessary qual parameter from rx status
      wl1271: added Juuso Oikarinen as module author
      wl1271: hack to disable filters
      wl1271: implement cmd_disconnect
      wl1271: workaround to send a disconnect before rejoining
      wl1271: add workaround to avoid distortion due to excessive tx power
      wl1271: enable HW_AVAILABLE interrupt to fix ELP
      wl1271: use acx_rx_config instead of join when updating filters
      wl1271: remove unnecessary joins and join only when the bssid changes
      wl1271: make sure PS is disabled in PLT
      wl1271: fix sparse warnings about undeclared functions
      wl1271: added missing packed modifier in some acx structs
      wl1271: fix endianess issues
      wl1271: added missing packed modifier in some cmd structs
      wl1271: use ieee80211_rx_ni()

Luis R. Rodriguez (2):
      ath9k_hw: run the carrier leakage calibration fix for ar9271 as well
      ath9k_hw: run ath9k_hw_9271_pa_cal() initial calibration

Marek Lindner (1):
      ath9k: adjust ahb callbacks to new struct layout to avoid compile errors

Matthieu CASTET (1):
      airo : allow supend with card without power management

Michael Buesch (4):
      b43/legacy: Fix usage of host_pci pointer
      ssb: Put host pointers into a union
      b43: Remove me as maintainer
      b43: Optimize PIO scratchbuffer usage

Reinette Chatre (5):
      iwlwifi: fix userspace setting of sleep_level_override
      iwlwifi: move iwl_setup_mac to iwlagn
      iwlwifi: move rate scaling structures to header file
      iwlagn: store station rate scale information in mac80211 station structure
      iwlwifi: remove duplicate defines

Rui Paulo (1):
      mesh: use set_bit() to set MESH_WORK_HOUSEKEEPING.

Samuel Ortiz (13):
      iwmc3200wifi: WPS support
      iwmc3200wifi: CT kill support
      iwmc3200wifi: Profile flags can be WPA1 or WPA2 not both
      iwmc3200wifi: Improve rx debug
      iwmc3200wifi: Update statistics notification structure
      iwmc3200wifi: Update fixed size config definitions
      iwmc3200wifi: Tx power setting
      iwmc3200wifi: SDIO disable race fix
      iwmc3200wifi: Check for cmd pointer before dereferencing it
      iwmc3200wifi: Do not handle wifi command if the interface is not ready
      iwmc3200wifi: Try shared auth when open WEP fails
      iwmc3200wifi: Support unexpected reboot barker
      iwmc3200wifi: Set wiphy firmware version

Sujith (1):
      ath9k: Fix TX hang poll routine

Teemu Paasikivi (5):
      wl1271: Added 5 GHz parameters for wl1273
      wl1271: Scan only enabled channels
      wl1271: Added support to scan on 5 GHz band
      wl1271: Added 5 GHz support to join and rx
      wl1271: Checking of rx descriptor status fixed

Vivek Natarajan (1):
      ath: Updates for regulatory and country codes.

Wey-Yi Guy (23):
      iwlwifi: remove duplicated/unused definition
      iwlwifi: additional items in sensitivity range table
      iwlwifi: dynamic allocate tx queue structure
      iwlwifi: showing accumulative ucode statistics counters
      iwlwifi: update channel switch command API
      iwlwifi: show current power save status reported by uCode
      iwlwifi: identify eeprom version for 6x50 series NIC
      iwlwifi: fix incorrect otp blocks number for 6x50 series
      iwlwifi: set auto clock gate disable bit for 6x00/6x50 series
      iwlwifi: no chain noise support for 6x50 series
      iwlwifi: rework for static power save
      iwlwifi: fix gain computation for 5000 series and up
      iwlwifi: separate led function from statistic notification
      iwlwifi: update bt co-exit configuration parameter
      iwlwifi: specify the valid tx/rx chain in device config structure
      iwlwifi: increase max tfd payload size
      iwlwifi: choose thermal throttle method based on device config
      iwlwifi: issue ct_kill host command based on device config
      iwlwifi: add channel switch support to 5000 series and up
      iwlwifi: remove unused parameters
      iwlwifi: remove duplicated define
      iwlwifi: update lowest API version support for 6x00 & 6x50 series
      iwlwifi: minor comments changes for wimax co-exist command

Zhu Yi (6):
      iwlwifi: use paged Rx
      iwmc3200wifi: add BGN sdio device id
      iwmc3200wifi: allow joining an existed IBSS network
      iwmc3200wifi: handle coexistence radio notification
      iwlwifi: fix use after free bug for paged rx
      iwlwifi: reuse page for notification packets

 MAINTAINERS                                  |    1 -
 drivers/net/wireless/airo.c                  |    3 +-
 drivers/net/wireless/ath/ar9170/ar9170.h     |    2 +-
 drivers/net/wireless/ath/ar9170/hw.h         |    4 +-
 drivers/net/wireless/ath/ar9170/main.c       |   11 +-
 drivers/net/wireless/ath/ar9170/usb.c        |   12 +-
 drivers/net/wireless/ath/ar9170/usb.h        |    2 +-
 drivers/net/wireless/ath/ath5k/ath5k.h       |   13 +
 drivers/net/wireless/ath/ath5k/attach.c      |    2 +
 drivers/net/wireless/ath/ath5k/phy.c         |  185 +-
 drivers/net/wireless/ath/ath5k/reg.h         |   11 +-
 drivers/net/wireless/ath/ath5k/reset.c       |   17 +-
 drivers/net/wireless/ath/ath9k/ahb.c         |    6 +-
 drivers/net/wireless/ath/ath9k/calib.c       |   28 +-
 drivers/net/wireless/ath/ath9k/xmit.c        |    2 +
 drivers/net/wireless/ath/regd.h              |    8 +
 drivers/net/wireless/ath/regd_common.h       |   32 +-
 drivers/net/wireless/b43/b43.h               |   16 +-
 drivers/net/wireless/b43/main.c              |    4 +-
 drivers/net/wireless/b43/pio.c               |   79 +-
 drivers/net/wireless/b43/xmit.c              |    7 +-
 drivers/net/wireless/b43legacy/main.c        |    4 +-
 drivers/net/wireless/iwlwifi/iwl-1000.c      |   17 +-
 drivers/net/wireless/iwlwifi/iwl-3945-hw.h   |   12 -
 drivers/net/wireless/iwlwifi/iwl-3945.c      |  237 +-
 drivers/net/wireless/iwlwifi/iwl-3945.h      |    8 -
 drivers/net/wireless/iwlwifi/iwl-4965-hw.h   |    3 -
 drivers/net/wireless/iwlwifi/iwl-4965.c      |  172 +-
 drivers/net/wireless/iwlwifi/iwl-5000.c      |  219 +-
 drivers/net/wireless/iwlwifi/iwl-6000.c      |  172 ++-
 drivers/net/wireless/iwlwifi/iwl-agn-rs.c    |  108 +-
 drivers/net/wireless/iwlwifi/iwl-agn-rs.h    |  101 +
 drivers/net/wireless/iwlwifi/iwl-agn.c       |  154 +-
 drivers/net/wireless/iwlwifi/iwl-calib.c     |    9 +-
 drivers/net/wireless/iwlwifi/iwl-commands.h  |   79 +-
 drivers/net/wireless/iwlwifi/iwl-core.c      |  260 ++-
 drivers/net/wireless/iwlwifi/iwl-core.h      |   24 +-
 drivers/net/wireless/iwlwifi/iwl-csr.h       |   11 +-
 drivers/net/wireless/iwlwifi/iwl-debug.h     |    1 +
 drivers/net/wireless/iwlwifi/iwl-debugfs.c   |  676 ++++--
 drivers/net/wireless/iwlwifi/iwl-dev.h       |   82 +-
 drivers/net/wireless/iwlwifi/iwl-eeprom.c    |    8 +
 drivers/net/wireless/iwlwifi/iwl-eeprom.h    |    5 +-
 drivers/net/wireless/iwlwifi/iwl-hcmd.c      |   23 +-
 drivers/net/wireless/iwlwifi/iwl-power.c     |   83 +-
 drivers/net/wireless/iwlwifi/iwl-rx.c        |  177 +-
 drivers/net/wireless/iwlwifi/iwl-scan.c      |   20 +-
 drivers/net/wireless/iwlwifi/iwl-spectrum.c  |    2 +-
 drivers/net/wireless/iwlwifi/iwl-sta.c       |   62 +-
 drivers/net/wireless/iwlwifi/iwl-tx.c        |   45 +-
 drivers/net/wireless/iwlwifi/iwl3945-base.c  |  266 ++-
 drivers/net/wireless/iwmc3200wifi/cfg80211.c |   47 +-
 drivers/net/wireless/iwmc3200wifi/commands.c |   31 +-
 drivers/net/wireless/iwmc3200wifi/commands.h |   70 +-
 drivers/net/wireless/iwmc3200wifi/fw.c       |    9 +
 drivers/net/wireless/iwmc3200wifi/iwm.h      |    6 +
 drivers/net/wireless/iwmc3200wifi/lmac.h     |    8 +
 drivers/net/wireless/iwmc3200wifi/main.c     |   46 +
 drivers/net/wireless/iwmc3200wifi/netdev.c   |    1 +
 drivers/net/wireless/iwmc3200wifi/rx.c       |   84 +-
 drivers/net/wireless/iwmc3200wifi/sdio.c     |   10 +-
 drivers/net/wireless/iwmc3200wifi/umac.h     |    5 +
 drivers/net/wireless/libertas/11d.c          |  696 ------
 drivers/net/wireless/libertas/11d.h          |  105 -
 drivers/net/wireless/libertas/Makefile       |    1 -
 drivers/net/wireless/libertas/assoc.c        |  445 ++++-
 drivers/net/wireless/libertas/assoc.h        |  141 ++-
 drivers/net/wireless/libertas/cmd.c          |  482 +----
 drivers/net/wireless/libertas/cmd.h          |  127 +-
 drivers/net/wireless/libertas/cmdresp.c      |  104 +-
 drivers/net/wireless/libertas/debugfs.c      |   27 +-
 drivers/net/wireless/libertas/decl.h         |   62 +-
 drivers/net/wireless/libertas/defs.h         |    1 -
 drivers/net/wireless/libertas/dev.h          |  424 +---
 drivers/net/wireless/libertas/host.h         |  960 +++++++--
 drivers/net/wireless/libertas/hostcmd.h      |  800 -------
 drivers/net/wireless/libertas/main.c         |  202 +--
 drivers/net/wireless/libertas/persistcfg.c   |    8 +-
 drivers/net/wireless/libertas/rx.c           |    2 +-
 drivers/net/wireless/libertas/scan.c         |  250 ++-
 drivers/net/wireless/libertas/scan.h         |   30 +
 drivers/net/wireless/libertas/tx.c           |    2 +-
 drivers/net/wireless/libertas/types.h        |    4 +-
 drivers/net/wireless/libertas/wext.c         |  144 +-
 drivers/net/wireless/libertas/wext.h         |    8 +
 drivers/net/wireless/orinoco/hw.c            |   33 +-
 drivers/net/wireless/orinoco/hw.h            |    3 +-
 drivers/net/wireless/orinoco/main.c          |   33 +-
 drivers/net/wireless/orinoco/orinoco.h       |    1 -
 drivers/net/wireless/rt2x00/Kconfig          |   30 +
 drivers/net/wireless/rt2x00/Makefile         |    2 +
 drivers/net/wireless/rt2x00/rt2800pci.c      | 3323 ++++++++++++++++++++++++++
 drivers/net/wireless/rt2x00/rt2800pci.h      | 1960 +++++++++++++++
 drivers/net/wireless/rt2x00/rt2x00.h         |    7 +
 drivers/net/wireless/rt2x00/rt2x00soc.c      |  159 ++
 drivers/net/wireless/rt2x00/rt2x00soc.h      |   52 +
 drivers/net/wireless/wl12xx/wl1251_main.c    |    7 +-
 drivers/net/wireless/wl12xx/wl1251_rx.c      |    2 +-
 drivers/net/wireless/wl12xx/wl1251_spi.c     |    2 +-
 drivers/net/wireless/wl12xx/wl1271.h         |   92 +-
 drivers/net/wireless/wl12xx/wl1271_acx.c     |  369 +++-
 drivers/net/wireless/wl12xx/wl1271_acx.h     |  586 ++---
 drivers/net/wireless/wl12xx/wl1271_boot.c    |  215 +-
 drivers/net/wireless/wl12xx/wl1271_boot.h    |   22 +-
 drivers/net/wireless/wl12xx/wl1271_cmd.c     |  329 ++-
 drivers/net/wireless/wl12xx/wl1271_cmd.h     |  115 +-
 drivers/net/wireless/wl12xx/wl1271_conf.h    |  911 +++++++
 drivers/net/wireless/wl12xx/wl1271_event.c   |   64 +-
 drivers/net/wireless/wl12xx/wl1271_event.h   |   30 +-
 drivers/net/wireless/wl12xx/wl1271_init.c    |  155 +-
 drivers/net/wireless/wl12xx/wl1271_init.h    |   53 +-
 drivers/net/wireless/wl12xx/wl1271_main.c    |  963 ++++++--
 drivers/net/wireless/wl12xx/wl1271_ps.c      |   68 +-
 drivers/net/wireless/wl12xx/wl1271_ps.h      |    2 +-
 drivers/net/wireless/wl12xx/wl1271_reg.h     |   47 +-
 drivers/net/wireless/wl12xx/wl1271_rx.c      |   86 +-
 drivers/net/wireless/wl12xx/wl1271_rx.h      |    4 +-
 drivers/net/wireless/wl12xx/wl1271_spi.c     |  311 ++--
 drivers/net/wireless/wl12xx/wl1271_spi.h     |   65 +-
 drivers/net/wireless/wl12xx/wl1271_tx.c      |   76 +-
 drivers/net/wireless/wl12xx/wl1271_tx.h      |   18 +-
 drivers/net/wireless/wl12xx/wl12xx_80211.h   |    4 +-
 drivers/net/wireless/zd1211rw/zd_chip.c      |    4 +-
 drivers/net/wireless/zd1211rw/zd_chip.h      |   18 +-
 drivers/net/wireless/zd1211rw/zd_mac.c       |  202 ++-
 drivers/net/wireless/zd1211rw/zd_mac.h       |   25 +-
 drivers/net/wireless/zd1211rw/zd_usb.c       |    4 +-
 drivers/ssb/driver_pcicore.c                 |    4 +-
 include/linux/ssb/ssb.h                      |   20 +-
 include/net/cfg80211.h                       |   31 +-
 include/net/mac80211.h                       |   32 +-
 net/mac80211/iface.c                         |    4 +-
 net/mac80211/mesh.c                          |    4 +-
 net/mac80211/mlme.c                          |   22 +-
 net/mac80211/rx.c                            |   21 +-
 net/mac80211/scan.c                          |   10 +-
 net/wireless/mlme.c                          |   45 +-
 137 files changed, 13469 insertions(+), 6003 deletions(-)
 delete mode 100644 drivers/net/wireless/libertas/11d.c
 delete mode 100644 drivers/net/wireless/libertas/11d.h
 delete mode 100644 drivers/net/wireless/libertas/hostcmd.h
 create mode 100644 drivers/net/wireless/rt2x00/rt2800pci.c
 create mode 100644 drivers/net/wireless/rt2x00/rt2800pci.h
 create mode 100644 drivers/net/wireless/rt2x00/rt2x00soc.c
 create mode 100644 drivers/net/wireless/rt2x00/rt2x00soc.h
 create mode 100644 drivers/net/wireless/wl12xx/wl1271_conf.h

Omnibus patch is available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-10-28.patch.bz2

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Wednesday 28 October 2009 22:10:32 John W. Linville wrote:
> Dave,
> 
> I let my patches pile-up!  Yikes!!
> 
> This request includes the usual ton of stuff for -next -- driver
> updates, fixes for some earlier -next stuff, a few cfg80211 changes to
> accomodate the libertas driver, etc.  Of note is the rt2800pci support
> added to the rt2x00 family.

Unfortunately rt2800pci support is non-functioning at the moment... :(

> Pleaset let me know if there are problems!

I find it rather disappointing that all my review comments regarding
rt2800pci support were just completely ignored and then the initial
patch was merged just as it was..

The way rt2800usb and rt2800pci drivers are designed really results
in making the task of adding working support for RT28x0 and RT30x0
chipsets to rt2x00 infrastructure more difficult and time consuming
than it should be... :(

-- 
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Wednesday 28 October 2009 22:56:00 Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 28 October 2009 22:10:32 John W. Linville wrote:
> > Dave,
> > 
> > I let my patches pile-up!  Yikes!!
> > 
> > This request includes the usual ton of stuff for -next -- driver
> > updates, fixes for some earlier -next stuff, a few cfg80211 changes to
> > accomodate the libertas driver, etc.  Of note is the rt2800pci support
> > added to the rt2x00 family.
> 
> Unfortunately rt2800pci support is non-functioning at the moment... :(
> 
> > Pleaset let me know if there are problems!
> 
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..
> 
> The way rt2800usb and rt2800pci drivers are designed really results
> in making the task of adding working support for RT28x0 and RT30x0
> chipsets to rt2x00 infrastructure more difficult and time consuming
> than it should be... :(

What is even more disappointing (especially after all that "working with"
preaching) is that the patch is now in net-next-2.6..

-- 
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 12:12:41 +0100

> What is even more disappointing (especially after all that "working with"
> preaching) is that the patch is now in net-next-2.6..

John is the wireless maintainer, I take his tree in since the changes
in there have his blessing.

If you have a problem with some change in there, work it out with him
and he'll send the fixed up changes to me thereafterwards.

I don't really see what the big deal is, any change can be reverted.

Re: pull request: wireless-next-2.6 2009-10-28

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 29 Oct 2009 12:12:41 +0100

> What is even more disappointing (especially after all that "working with"
> preaching) is that the patch is now in net-next-2.6..

John is the wireless maintainer, I take his tree in since the changes
in there have his blessing.

If you have a problem with some change in there, work it out with him
and he'll send the fixed up changes to me thereafterwards.

I don't really see what the big deal is, any change can be reverted.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Thursday 29 October 2009 13:15:09 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 12:12:41 +0100
> 
> > What is even more disappointing (especially after all that "working with"
> > preaching) is that the patch is now in net-next-2.6..
> 
> John is the wireless maintainer, I take his tree in since the changes
> in there have his blessing.
> 
> If you have a problem with some change in there, work it out with him
> and he'll send the fixed up changes to me thereafterwards.

What do you mean by that?

That *I* should be fixing the patch in question instead of the submitter?

Do some different rules apply in the networking than in other parts of
the kernel that I'm not aware of?

There were valid concerns raised on the initial rt2800pci patch submission,
yet two days later patch is in John's tree, after few more days it is in yours
tree and happily on his way into 2.6.33.

Until issues mentioned in:

	http://lkml.org/lkml/2009/10/17/81

are addressed rt2800pci shouldn't be queued for Linus' tree.

[ Please note that this driver doesn't work at all currently so the standard
  argument of having hardware support early upstream cannot be applied here. ]

--
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Thursday 29 October 2009 13:15:09 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Thu, 29 Oct 2009 12:12:41 +0100
> 
> > What is even more disappointing (especially after all that "working with"
> > preaching) is that the patch is now in net-next-2.6..
> 
> John is the wireless maintainer, I take his tree in since the changes
> in there have his blessing.
> 
> If you have a problem with some change in there, work it out with him
> and he'll send the fixed up changes to me thereafterwards.

What do you mean by that?

That *I* should be fixing the patch in question instead of the submitter?

Do some different rules apply in the networking than in other parts of
the kernel that I'm not aware of?

There were valid concerns raised on the initial rt2800pci patch submission,
yet two days later patch is in John's tree, after few more days it is in yours
tree and happily on his way into 2.6.33.

Until issues mentioned in:

	http://lkml.org/lkml/2009/10/17/81

are addressed rt2800pci shouldn't be queued for Linus' tree.

[ Please note that this driver doesn't work at all currently so the standard
  argument of having hardware support early upstream cannot be applied here. ]

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 13:45:05 +0100

> That *I* should be fixing the patch in question instead of the
> submitter?

I'm saying that you should work with John to have him send a revert or
whatever to me.

Re: pull request: wireless-next-2.6 2009-10-28

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 29 Oct 2009 13:45:05 +0100

> That *I* should be fixing the patch in question instead of the
> submitter?

I'm saying that you should work with John to have him send a revert or
whatever to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Thursday 29 October 2009 13:59:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 13:45:05 +0100
> 
> > That *I* should be fixing the patch in question instead of the
> > submitter?
> 
> I'm saying that you should work with John to have him send a revert or
> whatever to me.

This is your responsibility to deal with your downstream maintainers,
not mine and since you have accepted John's patch I'm asking you to
revert rt2800pci patch from your tree.

-- 
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Pekka Enberg]

Hi Bart,

On Thu, Oct 29, 2009 at 3:35 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> I'm saying that you should work with John to have him send a revert or
>> whatever to me.
>
> This is your responsibility to deal with your downstream maintainers,
> not mine and since you have accepted John's patch I'm asking you to
> revert rt2800pci patch from your tree.

So why don't you just send a patch to fix it up? I see you're doing
lots of cleanups to the staging drivers, why not direct some of that
energy to the drivers/net/wireless ones?

                         Pekka

Re: pull request: wireless-next-2.6 2009-10-28

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 14:35:54 +0100

> This is your responsibility to deal with your downstream maintainers,
> not mine and since you have accepted John's patch I'm asking you to
> revert rt2800pci patch from your tree.

That's not how it works Bart.  You should not be asking 'me' to do
anything on wireless bits, there is absolutely no reason to bypass
John in the workflow.

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Thursday 29 October 2009 14:53:36 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 14:35:54 +0100
> 
> > This is your responsibility to deal with your downstream maintainers,
> > not mine and since you have accepted John's patch I'm asking you to
> > revert rt2800pci patch from your tree.
> 
> That's not how it works Bart.  You should not be asking 'me' to do
> anything on wireless bits, there is absolutely no reason to bypass
> John in the workflow.

John has chosen to ignore my concerns and you are sending me back to him?

I like ping-pong but as a sport.

-- 
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Thursday 29 October 2009 14:53:36 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Thu, 29 Oct 2009 14:35:54 +0100
> 
> > This is your responsibility to deal with your downstream maintainers,
> > not mine and since you have accepted John's patch I'm asking you to
> > revert rt2800pci patch from your tree.
> 
> That's not how it works Bart.  You should not be asking 'me' to do
> anything on wireless bits, there is absolutely no reason to bypass
> John in the workflow.

John has chosen to ignore my concerns and you are sending me back to him?

I like ping-pong but as a sport.

-- 
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

Hi,

On Thursday 29 October 2009 14:52:50 Pekka Enberg wrote:
> Hi Bart,
> 
> On Thu, Oct 29, 2009 at 3:35 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> I'm saying that you should work with John to have him send a revert or
> >> whatever to me.
> >
> > This is your responsibility to deal with your downstream maintainers,
> > not mine and since you have accepted John's patch I'm asking you to
> > revert rt2800pci patch from your tree.
> 
> So why don't you just send a patch to fix it up? I see you're doing

"git revert a9b3a9f"

done.

Dave, if you have problems with executing the command locally I'll be
happy to supply you with the patch.

> lots of cleanups to the staging drivers, why not direct some of that
> energy to the drivers/net/wireless ones?

When did we start to apply "fix it yourself" rule instead of "submitter
should fix it" one to the _new_ code..

rt2800 drivers have their maintainers and I would like to know what they
are doing besides complaining about users and staging tree..

-- 
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 15:13:54 +0100

> John has chosen to ignore my concerns and you are sending me back to him?

That's exactly why I won't overreach his maintainership role,
because you're inability to interact with and work with the
wireless maintainer isn't my problem.

In case you're concerned, I actually agree with John and others
on this issue, and disagree with your position.

So even if I felt it legitimate to overreach John, I still wouldn't
make the change you are requesting in this case.

Does it really eat you so hard when someone disagrees with you?

That's not going to work in the long term Bart, if John disagrees with
you he's the maintainer of wireless and that's it.  You're going to
have to learn to work with people, and not just automatically go to a
"higher power" as soon as someone disagrees with you.

Re: pull request: wireless-next-2.6 2009-10-28

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 29 Oct 2009 15:13:54 +0100

> John has chosen to ignore my concerns and you are sending me back to him?

That's exactly why I won't overreach his maintainership role,
because you're inability to interact with and work with the
wireless maintainer isn't my problem.

In case you're concerned, I actually agree with John and others
on this issue, and disagree with your position.

So even if I felt it legitimate to overreach John, I still wouldn't
make the change you are requesting in this case.

Does it really eat you so hard when someone disagrees with you?

That's not going to work in the long term Bart, if John disagrees with
you he's the maintainer of wireless and that's it.  You're going to
have to learn to work with people, and not just automatically go to a
"higher power" as soon as someone disagrees with you.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 15:14:40 +0100

> Dave, if you have problems with executing the command locally I'll be
> happy to supply you with the patch.

This is not the issue.

The issue is that John disagrees with you can you can't handle
that.

So instead of continuing to discuss things with him and the
other wireless folks, you want me to just overreach everybody
and revert someone else's work.

I'm not going to do that sorry, learn how to work with the
wireless people instead.

Re: pull request: wireless-next-2.6 2009-10-28

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:

> In case you're concerned, I actually agree with John and others
> on this issue, and disagree with your position.

In this particular case, I think it makes more sense to duplicate the
code _especially_ because it's not working yet. That frees people
hacking on it of having to worry about breaking other devices.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Thursday 29 October 2009 15:20:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 15:13:54 +0100
> 
> > John has chosen to ignore my concerns and you are sending me back to him?
> 
> That's exactly why I won't overreach his maintainership role,
> because you're inability to interact with and work with the
> wireless maintainer isn't my problem.
> 
> In case you're concerned, I actually agree with John and others
> on this issue, and disagree with your position.
> 
> So even if I felt it legitimate to overreach John, I still wouldn't
> make the change you are requesting in this case.

Sorry but you are also wrong then and you are just in the way of progress.

> Does it really eat you so hard when someone disagrees with you?
> 
> That's not going to work in the long term Bart, if John disagrees with
> you he's the maintainer of wireless and that's it.  You're going to
> have to learn to work with people, and not just automatically go to a
> "higher power" as soon as someone disagrees with you.

I'm not going to waste my time on stupid or hopeless things just because you
or John like to call themselves "maintainers".

If Red Hat or some other company wants to hire me and pay me for spinning
inside networking bureaucracy than please contact me in private but as
long as it is my own time I'll just do what I think makes sense on technical
merits and not on who is the "maintainer" of this or that..

-- 
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Michael Buesch]

On Thursday 29 October 2009 15:21:01 David Miller wrote:
> The issue is that John disagrees with you can you can't handle
> that.
> 
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.

In the end this results in the driver maintainer being forced to maintain
code and handle bugreports for code that he disagrees with in the first place.
This is unacceptable and has to be resolved in some way.
If it's not possible to get it reverted through John (for whatever reason),
you're in charge to help the actual code maintainer out.

> I'm not going to do that sorry, learn how to work with the
> wireless people instead.

This is not the problem.
The problem is that stuff is merged without ack from the maintainer
and it's virtually impossible to get the stuff reverted. The only real
way for the maintainer to resolve this is 1) live with it or 2) fix it.
And that's bad, because it completely invalidates his priority queue.

Just like you must not bypass John, the driver maintainers must not be bypassed, too.
The quality control does _only_ work if nobody in the chain is bypassed.
But in this situation the quality control did already fail and it should be
tried hard to resolve (=revert) the situation instead of pointing at John.

-- 
Greetings, Michael.

Re: pull request: wireless-next-2.6 2009-10-28

[Michael Buesch]

On Thursday 29 October 2009 15:21:01 David Miller wrote:
> The issue is that John disagrees with you can you can't handle
> that.
> 
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.

In the end this results in the driver maintainer being forced to maintain
code and handle bugreports for code that he disagrees with in the first place.
This is unacceptable and has to be resolved in some way.
If it's not possible to get it reverted through John (for whatever reason),
you're in charge to help the actual code maintainer out.

> I'm not going to do that sorry, learn how to work with the
> wireless people instead.

This is not the problem.
The problem is that stuff is merged without ack from the maintainer
and it's virtually impossible to get the stuff reverted. The only real
way for the maintainer to resolve this is 1) live with it or 2) fix it.
And that's bad, because it completely invalidates his priority queue.

Just like you must not bypass John, the driver maintainers must not be bypassed, too.
The quality control does _only_ work if nobody in the chain is bypassed.
But in this situation the quality control did already fail and it should be
tried hard to resolve (=revert) the situation instead of pointing at John.

-- 
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Gertjan van Wingerde]

On Thu, Oct 29, 2009 at 3:39 PM, Michael Buesch <mb@bu3sch.de> wrote:
> On Thursday 29 October 2009 15:21:01 David Miller wrote:
>> The issue is that John disagrees with you can you can't handle
>> that.
>>
>> So instead of continuing to discuss things with him and the
>> other wireless folks, you want me to just overreach everybody
>> and revert someone else's work.
>
> In the end this results in the driver maintainer being forced to maintain
> code and handle bugreports for code that he disagrees with in the first place.
> This is unacceptable and has to be resolved in some way.
> If it's not possible to get it reverted through John (for whatever reason),
> you're in charge to help the actual code maintainer out.
>
>> I'm not going to do that sorry, learn how to work with the
>> wireless people instead.
>
> This is not the problem.
> The problem is that stuff is merged without ack from the maintainer
> and it's virtually impossible to get the stuff reverted. The only real
> way for the maintainer to resolve this is 1) live with it or 2) fix it.
> And that's bad, because it completely invalidates his priority queue.
>
> Just like you must not bypass John, the driver maintainers must not be bypassed, too.
> The quality control does _only_ work if nobody in the chain is bypassed.
> But in this situation the quality control did already fail and it should be
> tried hard to resolve (=revert) the situation instead of pointing at John.
>

Hold on here. In this case it is the driver maintainer (i.e. Ivo for
the rt2x00 project) that
submitted this driver for inclusion, so the driver maintainer has not
been bypassed in
this case.

Apparently Bart has issues with the code submitted by the maintainers
and has been
unsuccessful in convincing others about these issues.

---
Gertjan.

Re: pull request: wireless-next-2.6 2009-10-28

[Michael Buesch]

On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
> the rt2x00 project) that
> submitted this driver for inclusion, so the driver maintainer has not
> been bypassed in
> this case.
> 
> Apparently Bart has issues with the code submitted by the maintainers
> and has been
> unsuccessful in convincing others about these issues.

So Bart is not a maintainer? That of course changes the situation.

-- 
Greetings, Michael.

Re: pull request: wireless-next-2.6 2009-10-28

[Michael Buesch]

On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
> the rt2x00 project) that
> submitted this driver for inclusion, so the driver maintainer has not
> been bypassed in
> this case.
> 
> Apparently Bart has issues with the code submitted by the maintainers
> and has been
> unsuccessful in convincing others about these issues.

So Bart is not a maintainer? That of course changes the situation.

-- 
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Luis R. Rodriguez]

On Thu, Oct 29, 2009 at 7:48 AM, Michael Buesch <mb@bu3sch.de> wrote:
> On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
>> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
>> the rt2x00 project) that
>> submitted this driver for inclusion, so the driver maintainer has not
>> been bypassed in
>> this case.
>>
>> Apparently Bart has issues with the code submitted by the maintainers
>> and has been
>> unsuccessful in convincing others about these issues.
>
> So Bart is not a maintainer? That of course changes the situation.

But you were :-P

  Luis

Re: pull request: wireless-next-2.6 2009-10-28

[Luis R. Rodriguez]

On Thu, Oct 29, 2009 at 7:48 AM, Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:
> On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
>> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
>> the rt2x00 project) that
>> submitted this driver for inclusion, so the driver maintainer has not
>> been bypassed in
>> this case.
>>
>> Apparently Bart has issues with the code submitted by the maintainers
>> and has been
>> unsuccessful in convincing others about these issues.
>
> So Bart is not a maintainer? That of course changes the situation.

But you were :-P

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Thursday 29 October 2009 15:21:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 15:14:40 +0100
> 
> > Dave, if you have problems with executing the command locally I'll be
> > happy to supply you with the patch.
> 
> This is not the issue.
> 
> The issue is that John disagrees with you can you can't handle
> that.
> 
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.

Lets look at the technical merits of this work.

It is 5 KLOC of dead code and it should be 1-2 KLOC of working code
(we may turn the blink eye on "working" part but FFS at least fix other
parts)..

Hey, Linus.  We have a new driver for ya.  It doesn't work, has design
problems and is not even half-finished but most wireless folks are fine
with it!

I wonder when things went so wrong here..

> I'm not going to do that sorry, learn how to work with the
> wireless people instead.

This is a waste of time since technical merit doesn't find much love there.

Sorry Dave but you're making me go over your head now and go into unpleasant
mode again..

Looking on how you just reverted cmd64x change which you were so proud while
taking IDE over shows where the real problem is -- in subsystems supervised
by you loyalty and rank is everything while you are busy playing the pointy
haired boss everywhere from arm to ide.

--
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Pekka Enberg]

Hi Bart,

On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> lots of cleanups to the staging drivers, why not direct some of that
>> energy to the drivers/net/wireless ones?
>
> When did we start to apply "fix it yourself" rule instead of "submitter
> should fix it" one to the _new_ code..

Don't be silly, I didn't say that.

I was simply pointing out that your time would probably be better
spent in improving the "proper" ralink wireless drivers but if you
_really_ prefer to spend your time in pointless arguments, go ahead.
It should be pretty obvious by now that the best way to improve things
is to work with the relevant maintainers, not against them. (Unless
you wish your work to be ignored, of course.)

                        Pekka

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Thursday 29 October 2009 20:45:07 Pekka Enberg wrote:
> Hi Bart,
> 
> On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> lots of cleanups to the staging drivers, why not direct some of that
> >> energy to the drivers/net/wireless ones?
> >
> > When did we start to apply "fix it yourself" rule instead of "submitter
> > should fix it" one to the _new_ code..
> 
> Don't be silly, I didn't say that.

Sorry, I must have misunderstood you.

> I was simply pointing out that your time would probably be better
> spent in improving the "proper" ralink wireless drivers but if you

Thanks for the concern.  However recent discussions made my realize how
I should really be spending my time effectively way too well.

> _really_ prefer to spend your time in pointless arguments, go ahead.

I don't think that my technical arguments are pointless.

Quite the contrary, I'm pretty confident that addressing my review concerns
would result in better RT28x00 / RT30x0 support in the very near future.

> It should be pretty obvious by now that the best way to improve things
> is to work with the relevant maintainers, not against them. (Unless
> you wish your work to be ignored, of course.)

I work with a lot of other maintainers.  I would say that providing valuable
review feedback is also "working with" (at least I would be very happy with
such feedback in my projects).

--
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Thursday 29 October 2009 20:45:07 Pekka Enberg wrote:
> Hi Bart,
> 
> On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
> <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> lots of cleanups to the staging drivers, why not direct some of that
> >> energy to the drivers/net/wireless ones?
> >
> > When did we start to apply "fix it yourself" rule instead of "submitter
> > should fix it" one to the _new_ code..
> 
> Don't be silly, I didn't say that.

Sorry, I must have misunderstood you.

> I was simply pointing out that your time would probably be better
> spent in improving the "proper" ralink wireless drivers but if you

Thanks for the concern.  However recent discussions made my realize how
I should really be spending my time effectively way too well.

> _really_ prefer to spend your time in pointless arguments, go ahead.

I don't think that my technical arguments are pointless.

Quite the contrary, I'm pretty confident that addressing my review concerns
would result in better RT28x00 / RT30x0 support in the very near future.

> It should be pretty obvious by now that the best way to improve things
> is to work with the relevant maintainers, not against them. (Unless
> you wish your work to be ignored, of course.)

I work with a lot of other maintainers.  I would say that providing valuable
review feedback is also "working with" (at least I would be very happy with
such feedback in my projects).

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Pekka Enberg]

Hi Bart,

On Thu, Oct 29, 2009 at 11:48 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> _really_ prefer to spend your time in pointless arguments, go ahead.
>
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.

I don't think your technical arguments are pointless either. However,
asking Dave to revert something over John and then arguing about it is
pointless and will likely just piss people off and make them ignore
you.

                        Pekka

Re: pull request: wireless-next-2.6 2009-10-28

[Pekka Enberg]

Hi Bart,

On Thu, Oct 29, 2009 at 11:48 PM, Bartlomiej Zolnierkiewicz
<bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> _really_ prefer to spend your time in pointless arguments, go ahead.
>
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.

I don't think your technical arguments are pointless either. However,
asking Dave to revert something over John and then arguing about it is
pointless and will likely just piss people off and make them ignore
you.

                        Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Thu, 2009-10-29 at 22:48 +0100, Bartlomiej Zolnierkiewicz wrote:

> I don't think that my technical arguments are pointless.
> 
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.

So you know how to make the driver better, whine that it doesn't work,
but don't help out either. Hey, good way to collaborate!

> > It should be pretty obvious by now that the best way to improve things
> > is to work with the relevant maintainers, not against them. (Unless
> > you wish your work to be ignored, of course.)
> 
> I work with a lot of other maintainers.  I would say that providing valuable
> review feedback is also "working with" (at least I would be very happy with
> such feedback in my projects).

Face it though, people have read your feedback, thought about it, and
decided to disagree. You seem to have a childish problem with that,
appealing to higher authority to get your way just makes you look more
childish.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: pull request: wireless-next-2.6 2009-10-28

[Jarek Poplawski]

On 30-10-2009 08:00, Johannes Berg wrote:
> On Thu, 2009-10-29 at 22:48 +0100, Bartlomiej Zolnierkiewicz wrote:
> 
>> I don't think that my technical arguments are pointless.
>>
>> Quite the contrary, I'm pretty confident that addressing my review concerns
>> would result in better RT28x00 / RT30x0 support in the very near future.
> 
> So you know how to make the driver better, whine that it doesn't work,
> but don't help out either. Hey, good way to collaborate!
> 
>>> It should be pretty obvious by now that the best way to improve things
>>> is to work with the relevant maintainers, not against them. (Unless
>>> you wish your work to be ignored, of course.)
>> I work with a lot of other maintainers.  I would say that providing valuable
>> review feedback is also "working with" (at least I would be very happy with
>> such feedback in my projects).
> 
> Face it though, people have read your feedback, thought about it, and
> decided to disagree. You seem to have a childish problem with that,
> appealing to higher authority to get your way just makes you look more
> childish.

There are various ways to disagree, and ignoring by John questions
from a merited developer both in this referenced lkml and current
threads looks at least strange (if not offensive) as well.

Jarek P.

Re: pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

On Fri, Oct 30, 2009 at 11:06:16AM +0000, Jarek Poplawski wrote:

> There are various ways to disagree, and ignoring by John questions
> from a merited developer both in this referenced lkml and current
> threads looks at least strange (if not offensive) as well.

Did you read the thread for which Bartlomiej provided a link earlier?
There were ten responses (only three of them from him) in that thread.
His comments were not ignored, they were rejected.

Ever since Bartlomiej decided to tear himself away from
drivers/staging, he has been nothing but negative -- petty, whining,
indignat, whatever.  Just what has he done to merit any special
consideration here?  Why should he have any sort of veto over rt2x00?

And of all things on which to take a stand -- how dare the rt2x00 guys
use two header files instead of three?  The nerve of those people!!!

Ridiculous...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

On Fri, Oct 30, 2009 at 11:06:16AM +0000, Jarek Poplawski wrote:

> There are various ways to disagree, and ignoring by John questions
> from a merited developer both in this referenced lkml and current
> threads looks at least strange (if not offensive) as well.

Did you read the thread for which Bartlomiej provided a link earlier?
There were ten responses (only three of them from him) in that thread.
His comments were not ignored, they were rejected.

Ever since Bartlomiej decided to tear himself away from
drivers/staging, he has been nothing but negative -- petty, whining,
indignat, whatever.  Just what has he done to merit any special
consideration here?  Why should he have any sort of veto over rt2x00?

And of all things on which to take a stand -- how dare the rt2x00 guys
use two header files instead of three?  The nerve of those people!!!

Ridiculous...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

On Thu, Oct 29, 2009 at 10:48:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 29 October 2009 20:45:07 Pekka Enberg wrote:

> > I was simply pointing out that your time would probably be better
> > spent in improving the "proper" ralink wireless drivers but if you
> 
> Thanks for the concern.  However recent discussions made my realize how
> I should really be spending my time effectively way too well.
> 
> > _really_ prefer to spend your time in pointless arguments, go ahead.
> 
> I don't think that my technical arguments are pointless.

More like "petty"...

> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.

Yeah, maybe.  Or they could just waste someone's time mashing
together some definitions to prematurely turn two header files into
three instead of spending that time on resolving operational issues.
In either case it is a judgment call, and IMHO not your call to make.

> > It should be pretty obvious by now that the best way to improve things
> > is to work with the relevant maintainers, not against them. (Unless
> > you wish your work to be ignored, of course.)
> 
> I work with a lot of other maintainers.  I would say that providing valuable
> review feedback is also "working with" (at least I would be very happy with
> such feedback in my projects).

"Valuable" feedback would be welcome.  In fact, your initial feedback
in this case was welcome -- even moreso had it included a patch.

Your arrogant follow-ups and self-righteous indignation, however,
is quite a bit less welcome.  Please take it somewhere else.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: pull request: wireless-next-2.6 2009-10-28

[Jarek Poplawski]

On Fri, Oct 30, 2009 at 11:02:24AM -0400, John W. Linville wrote:
> On Fri, Oct 30, 2009 at 11:06:16AM +0000, Jarek Poplawski wrote:
> 
> > There are various ways to disagree, and ignoring by John questions
> > from a merited developer both in this referenced lkml and current
> > threads looks at least strange (if not offensive) as well.
> 
> Did you read the thread for which Bartlomiej provided a link earlier?
> There were ten responses (only three of them from him) in that thread.
> His comments were not ignored, they were rejected.
> 
> Ever since Bartlomiej decided to tear himself away from
> drivers/staging, he has been nothing but negative -- petty, whining,
> indignat, whatever.  Just what has he done to merit any special
> consideration here?  Why should he have any sort of veto over rt2x00?
> 
> And of all things on which to take a stand -- how dare the rt2x00 guys
> use two header files instead of three?  The nerve of those people!!!
> 
> Ridiculous...

Maybe. Different tastes for sure, so simply no good solution.

Anyway, my point was somewhere else: Davem could be a good example;-)
I simply can't imagine a thread with such concerns left completely
uncommented before merging a patch. It's not about convincing anybody.
Usually you know at least if the concern is dismissed, or valid, but
fixable. (Sometimes you can even read between lines, or explicit, what
he really thinks...)

This discussion is mainly around trying to omit a maintainer with
"higher authority". Of course it's a mortal sin! ...Except, when the
maintainer doesn't seem to respond at all.

BTW, it seems Bartlomiej's main argument in the current thread has
changed to the non-working driver, so ridiculous only if you have a
clue.

Jarek P.

Re: pull request: wireless-next-2.6 2009-10-28

[Jarek Poplawski]

On Fri, Oct 30, 2009 at 11:02:24AM -0400, John W. Linville wrote:
> On Fri, Oct 30, 2009 at 11:06:16AM +0000, Jarek Poplawski wrote:
> 
> > There are various ways to disagree, and ignoring by John questions
> > from a merited developer both in this referenced lkml and current
> > threads looks at least strange (if not offensive) as well.
> 
> Did you read the thread for which Bartlomiej provided a link earlier?
> There were ten responses (only three of them from him) in that thread.
> His comments were not ignored, they were rejected.
> 
> Ever since Bartlomiej decided to tear himself away from
> drivers/staging, he has been nothing but negative -- petty, whining,
> indignat, whatever.  Just what has he done to merit any special
> consideration here?  Why should he have any sort of veto over rt2x00?
> 
> And of all things on which to take a stand -- how dare the rt2x00 guys
> use two header files instead of three?  The nerve of those people!!!
> 
> Ridiculous...

Maybe. Different tastes for sure, so simply no good solution.

Anyway, my point was somewhere else: Davem could be a good example;-)
I simply can't imagine a thread with such concerns left completely
uncommented before merging a patch. It's not about convincing anybody.
Usually you know at least if the concern is dismissed, or valid, but
fixable. (Sometimes you can even read between lines, or explicit, what
he really thinks...)

This discussion is mainly around trying to omit a maintainer with
"higher authority". Of course it's a mortal sin! ...Except, when the
maintainer doesn't seem to respond at all.

BTW, it seems Bartlomiej's main argument in the current thread has
changed to the non-working driver, so ridiculous only if you have a
clue.

Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Friday 30 October 2009 16:02:24 John W. Linville wrote:

> Ever since Bartlomiej decided to tear himself away from
> drivers/staging, he has been nothing but negative -- petty, whining,

I think that you should ping Greg about this since somebody impersonating
for me is sending him patches.  Last week alone over 20 such patches were
merged -- who knows what this person might be planning.. ;)

Probably the following patch was the source of confusion:

	http://patchwork.kernel.org/patch/55076/

It just aligns my personal interests w/ ongoing work done by other people,
hch is working on mac80211 via driver and Greg has announced some time ago
that he was going to work on proper rtl819x support.

-- 
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Friday 30 October 2009 16:02:24 John W. Linville wrote:

> Ever since Bartlomiej decided to tear himself away from
> drivers/staging, he has been nothing but negative -- petty, whining,

I think that you should ping Greg about this since somebody impersonating
for me is sending him patches.  Last week alone over 20 such patches were
merged -- who knows what this person might be planning.. ;)

Probably the following patch was the source of confusion:

	http://patchwork.kernel.org/patch/55076/

It just aligns my personal interests w/ ongoing work done by other people,
hch is working on mac80211 via driver and Greg has announced some time ago
that he was going to work on proper rtl819x support.

-- 
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Ingo Molnar]

* John W. Linville <linville@tuxdriver.com> wrote:

> On Fri, Oct 30, 2009 at 11:06:16AM +0000, Jarek Poplawski wrote:
> 
> > There are various ways to disagree, and ignoring by John questions
> > from a merited developer both in this referenced lkml and current
> > threads looks at least strange (if not offensive) as well.
> 
> Did you read the thread for which Bartlomiej provided a link earlier? 
> There were ten responses (only three of them from him) in that thread. 
> His comments were not ignored, they were rejected.
> 
> Ever since Bartlomiej decided to tear himself away from 
> drivers/staging, he has been nothing but negative -- petty, whining, 
> indignat, whatever.  Just what has he done to merit any special 
> consideration here?  Why should he have any sort of veto over rt2x00?

I got curious, as my past experience with Bartlomiej is that he is a 
factual, reliable, knowledgable upstream driver developer interested in 
difficult pieces of code others are reluctant to touch, for whom it is 
rather atypical to get 'petty, whining, indignant'.

So i have read the thread you and Bartlomiej referenced:

    http://lkml.org/lkml/2009/10/17/81

... and my understanding of that discussion is very different from 
yours. Here is my annotated history of the beginnings of that 
discussion:

Bartlomiej (in <200910171654.03344.bzolnier@gmail.com>) started his 
review of the driver with:

 | First let me say that I'm very happy to see this patch finally being 
 | submitted and I appreciate the effort..
 |
 | (I'll give it a spin on Eee 901 w/ 2.6.32-rc5 sometime later..)

Very friendly and constructive. Pretty much the Bartlomiej i have known 
for years.

Then he continues with his technical observations:

 | Now to the less happy part..
 |
 | I also used the opportunity to take a closer look at this driver and 
 | it seems that it needlessly adds around 2 KLOC to kernel by 
 | duplicating the common content of rt2800usb.h to rt2800pci.h instead 
 | of moving it to the shared header (like it is done in the staging 
 | crap drivers):
 |
 | [...]
 |
 | All in all, the total amount of the kernel code needed for 
 | implementing rt2800pci functionality should 1-2 KLOC instead of the 
 | current 5 KLOC.

Looks like a valid technical point that should be replied to in ernest.

Johannes Berg's first reply (<1255792104.3434.2.camel@johannes.local>) 
ignored Bartlomiej's friendly approach and launched a combative, 
emotion-laden, unconstructive (and technically inapposite) attack:

 | Tell me you're kidding -- comparing 2k duplicated LOC with a driver 
 | that ships its own wifi stack?

Bartlomiej's reply (<1255792104.3434.2.camel@johannes.local>) ignored 
the attack (gracefully) and replied to the technical portion only:

 | > Tell me you're kidding -- comparing 2k duplicated LOC with a driver 
 | > that ships its own wifi stack?
 |
 | Why would I be?
 |
 | 1) The patch is submitted to kernel _proper_ not kernel staging so I 
 | see no excuse for duplicating 2-4 KLOC and it should be fixed.
 |
 | 2) The fact that the some staging driver consists in 90% of crap 
 | doesn't mean that it doesn't have some good design ideas..  (i.e. 
 | abstracting chipset registers access in a discussed case)

To which technical point Johannes elected not to reply. (Effectively 
conceding Bartlomiej's point as per lkml discussion rules.)

[ There are similar patterns in other threads of this discussion - the 
  reply in (<200910181859.22413.IvDoorn@gmail.com>) and followups 
  were similarly dismissive (while not as combative as Johannes's reply) 
  - with an often offensive tone against Bartlomiej. ]

Bartlomiej followed up with his test results in another message in 
<200910172318.56929.bzolnier@gmail.com>. Corroborated by Luis Correia in 
<efe7343f0910180240o223ac346j3dd7c45c7460ec41@mail.gmail.com>. Both 
messages were factual, constructive and friendly.

Neither failure report was replied to in that thread and remains ignored 
up to today, 15 days down the line.

Alas, the portion of the story that is visible in that discussion on 
lkml contradicts your claim almost 180 degrees. The person being 
attacked there was Bartlomiej and i simply dont see where you got the 
conclusion from that he was 'petty, whining, indignant'.

Now look at the aftermath from Bartlomiej's perspective: this 
non-working driver with arguably unresponsive, unfriendly maintainers 
got pulled twice (first by you and then by David), and it is now on the 
unstoppable path upstream. By omission he's been forced to raise these 
issues at every hop that pulls this piece of code - and it was not his 
choice to be exposed to such a spiral of a workflow.

I can understand David trusting your judgement and not wanting to get 
involved in the fine details, but having read the surrounding discussion 
i dont understand your interpretation of the events, and i dont 
understand on what basis you launched your very serious accusation, that 
he is being 'petty, whining, indignant'. Every reply from him in that 
thread is the exact opposite of that. Care to elaborate?

Thanks,

	Ingo

Re: pull request: wireless-next-2.6 2009-10-28

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:

> So i have read the thread you and Bartlomiej referenced:
> 
>     http://lkml.org/lkml/2009/10/17/81
> 
> ... and my understanding of that discussion is very different from 
> yours. Here is my annotated history of the beginnings of that 
> discussion:

[snip]

You shouldn't ignore all previous interaction between Bart and us --
which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892

Of course we were biased when he came around with that petty code
duplication argument, since it seemed to support only his agenda of
working only with the staging drivers.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: pull request: wireless-next-2.6 2009-10-28

[Ingo Molnar]

* Johannes Berg <johannes@sipsolutions.net> wrote:

> On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:
> 
> > So i have read the thread you and Bartlomiej referenced:
> > 
> >     http://lkml.org/lkml/2009/10/17/81
> > 
> > ... and my understanding of that discussion is very different from 
> > yours. Here is my annotated history of the beginnings of that 
> > discussion:
> 
> [snip]
> 
> You shouldn't ignore all previous interaction between Bart and us -- 
> which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892

I have seen that exchange too - here's the lkml.org link for those who 
like the lkml.org format:

   http://lkml.org/lkml/2009/10/13/186

And i can see no supporting fact here either, for the (very serious) 
accusation launched by John Linville, that Bartlomiej is 'petty, 
whining, indignant'. In my reading he is the opposite of that, even in 
this second thread you point out.

So, no matter how much you disagree about the code and its direction, 
please either back up your assertion with specific links to a pattern of 
misbehavior or apologize for the ad-hominen attacks against Bartlomiej.

> Of course we were biased when he came around with that petty code 
> duplication argument, since it seemed to support only his agenda of 
> working only with the staging drivers.

Why do you think that disagreeing in the past gives you the right to get 
into ad-hominens? You should concentrate on the code and on the 
technical side, not on the person making the argument.

Also, why do you characterise a code duplication argument as 'petty'?

Bloat and unnecessary technical forking is the #1 enemy of Linux. 
Integrating code and infrastructure is the #1 strength of Linux.

Upstream subsystems/drivers running away with their private 
implementations has its clear costs:

 - introduces bugs
 - makes drivers shallow in practice 
 - makes unifying drivers and infrastructure so hard down the road
 - bloats the code, increases i$ footprint

I routinely refuse patches based on 'please dont duplicate' arguments, 
in fact i did it once today already.

[ I dont know why drivers/staging/ is even an argument here - he argued
  about the technical qualities of a new upstream driver, not about a
  staging driver. Upstream drivers are to be held to higher standards,
  _especially_ now that we can isolate not-clean-enough-yet drivers into
  drivers/staging/, without hurting users. ]

Thanks,

	Ingo

Re: pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

On Mon, Nov 02, 2009 at 10:10:38AM +0100, Ingo Molnar wrote:
> 
> * John W. Linville <linville@tuxdriver.com> wrote:

<snip>

> > Ever since Bartlomiej decided to tear himself away from 
> > drivers/staging, he has been nothing but negative -- petty, whining, 
> > indignat, whatever.  Just what has he done to merit any special 
> > consideration here?  Why should he have any sort of veto over rt2x00?
> 
> I got curious, as my past experience with Bartlomiej is that he is a 
> factual, reliable, knowledgable upstream driver developer interested in 
> difficult pieces of code others are reluctant to touch, for whom it is 
> rather atypical to get 'petty, whining, indignant'.
 
YMMV...

<snip>

> Bartlomiej's reply (<1255792104.3434.2.camel@johannes.local>) ignored 
> the attack (gracefully) and replied to the technical portion only:
> 
>  | > Tell me you're kidding -- comparing 2k duplicated LOC with a driver 
>  | > that ships its own wifi stack?
>  |
>  | Why would I be?
>  |
>  | 1) The patch is submitted to kernel _proper_ not kernel staging so I 
>  | see no excuse for duplicating 2-4 KLOC and it should be fixed.
>  |
>  | 2) The fact that the some staging driver consists in 90% of crap 
>  | doesn't mean that it doesn't have some good design ideas..  (i.e. 
>  | abstracting chipset registers access in a discussed case)
> 
> To which technical point Johannes elected not to reply. (Effectively 
> conceding Bartlomiej's point as per lkml discussion rules.)

Really?  "Last post wins" is the rule?  I hope you are joking...

> I can understand David trusting your judgement and not wanting to get 
> involved in the fine details, but having read the surrounding discussion 
> i dont understand your interpretation of the events, and i dont 
> understand on what basis you launched your very serious accusation, that 
> he is being 'petty, whining, indignant'. Every reply from him in that 
> thread is the exact opposite of that. Care to elaborate?

Despite your links, we seem to be reading different threads.  I'm not
sure I can reach your conclusions even with the most generous reading
of Bartlomiej's posts and the most critical readings of _everyone_
else's.

It seems Bartlomiej has taken it personally that we don't like having
the Ralink vendor drivers in the staging tree and he has decided to be
an irritant in linux-wireless as some sort of revenge.  As a bonus,
he has thrown-in some random ramblings attacking the inclusion of
Pulseaudio in Fedora and criticizing Dave's handling of the ide tree.
And worst of all he has chosen to make a big stink about whether or
not the rt2x00 family of drivers (which shares tons of code already,
BTW) is sharing enough code for his taste in drivers that are currently
under active development.

Now you have come along to defend him for whatever your reasons,
and you have chosen to act as if Bartlomiej has been ignored simply
because you don't like the responses he got.  Further, you seem to
expect me to have given him some veto over a driver for which has
has contributed essentially nothing[1].  Why?  Simply because he doesn't
agree with the driver maintainer's JUDGMENT CALL?  Or mine?  Or Dave's?
And for all his objections, he can't be bothered to offer a patch?

I can only guess as to why you are being deferential to Bartlomiej
and overlooking not only how he has treated the rest of us but also
that his technical complaint is minor.  I can only ask you to consider
that maybe Bartlomiej is not so aggrieved as he claims.

John

[1] Even his bug reports and code reviews have clearly been from the
perspective of "you should just be using the staging driver".
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

On Mon, Nov 02, 2009 at 11:07:02AM +0100, Ingo Molnar wrote:
> 
> * Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> > On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:
> > 
> > > So i have read the thread you and Bartlomiej referenced:
> > > 
> > >     http://lkml.org/lkml/2009/10/17/81
> > > 
> > > ... and my understanding of that discussion is very different from 
> > > yours. Here is my annotated history of the beginnings of that 
> > > discussion:
> > 
> > [snip]
> > 
> > You shouldn't ignore all previous interaction between Bart and us -- 
> > which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892
> 
> I have seen that exchange too - here's the lkml.org link for those who 
> like the lkml.org format:
> 
>    http://lkml.org/lkml/2009/10/13/186
> 
> And i can see no supporting fact here either, for the (very serious) 
> accusation launched by John Linville, that Bartlomiej is 'petty, 
> whining, indignant'. In my reading he is the opposite of that, even in 
> this second thread you point out.

Again, you seem to be very generous to Bartlomiej and very critical of
the rest of us in your readings.

> So, no matter how much you disagree about the code and its direction, 
> please either back up your assertion with specific links to a pattern of 
> misbehavior or apologize for the ad-hominen attacks against Bartlomiej.

His behavior is evident in the threads you cited.  How you do not
see that is a mystery.

> > Of course we were biased when he came around with that petty code 
> > duplication argument, since it seemed to support only his agenda of 
> > working only with the staging drivers.
> 
> Why do you think that disagreeing in the past gives you the right to get 
> into ad-hominens? You should concentrate on the code and on the 
> technical side, not on the person making the argument.
> 
> Also, why do you characterise a code duplication argument as 'petty'?

Did you actually look at the thread?  Or did you simply here "code
duplication" and run with it?
 
> Bloat and unnecessary technical forking is the #1 enemy of Linux. 
> Integrating code and infrastructure is the #1 strength of Linux.
> 
> Upstream subsystems/drivers running away with their private 
> implementations has its clear costs:

...which has nothing to do with the case at hand.  Please do not
perpetuate this myth.  If anything, your argument applies far more
to the drivers in staging that Bartlomiej has focused his attention
upon until recently.

<snip>

> [ I dont know why drivers/staging/ is even an argument here - he argued
>   about the technical qualities of a new upstream driver, not about a
>   staging driver. Upstream drivers are to be held to higher standards,
>   _especially_ now that we can isolate not-clean-enough-yet drivers into
>   drivers/staging/, without hurting users. ]

If you had been keeping-up, you would realize that Bartlomiej is upset
about our criticisms of the Ralink drivers in staging.  That would seem
to be the reason he has made himself such an irritant in linux-wireless
over the past few weeks.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

On Mon, Nov 02, 2009 at 11:07:02AM +0100, Ingo Molnar wrote:
> 
> * Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> > On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:
> > 
> > > So i have read the thread you and Bartlomiej referenced:
> > > 
> > >     http://lkml.org/lkml/2009/10/17/81
> > > 
> > > ... and my understanding of that discussion is very different from 
> > > yours. Here is my annotated history of the beginnings of that 
> > > discussion:
> > 
> > [snip]
> > 
> > You shouldn't ignore all previous interaction between Bart and us -- 
> > which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892
> 
> I have seen that exchange too - here's the lkml.org link for those who 
> like the lkml.org format:
> 
>    http://lkml.org/lkml/2009/10/13/186
> 
> And i can see no supporting fact here either, for the (very serious) 
> accusation launched by John Linville, that Bartlomiej is 'petty, 
> whining, indignant'. In my reading he is the opposite of that, even in 
> this second thread you point out.

Again, you seem to be very generous to Bartlomiej and very critical of
the rest of us in your readings.

> So, no matter how much you disagree about the code and its direction, 
> please either back up your assertion with specific links to a pattern of 
> misbehavior or apologize for the ad-hominen attacks against Bartlomiej.

His behavior is evident in the threads you cited.  How you do not
see that is a mystery.

> > Of course we were biased when he came around with that petty code 
> > duplication argument, since it seemed to support only his agenda of 
> > working only with the staging drivers.
> 
> Why do you think that disagreeing in the past gives you the right to get 
> into ad-hominens? You should concentrate on the code and on the 
> technical side, not on the person making the argument.
> 
> Also, why do you characterise a code duplication argument as 'petty'?

Did you actually look at the thread?  Or did you simply here "code
duplication" and run with it?
 
> Bloat and unnecessary technical forking is the #1 enemy of Linux. 
> Integrating code and infrastructure is the #1 strength of Linux.
> 
> Upstream subsystems/drivers running away with their private 
> implementations has its clear costs:

...which has nothing to do with the case at hand.  Please do not
perpetuate this myth.  If anything, your argument applies far more
to the drivers in staging that Bartlomiej has focused his attention
upon until recently.

<snip>

> [ I dont know why drivers/staging/ is even an argument here - he argued
>   about the technical qualities of a new upstream driver, not about a
>   staging driver. Upstream drivers are to be held to higher standards,
>   _especially_ now that we can isolate not-clean-enough-yet drivers into
>   drivers/staging/, without hurting users. ]

If you had been keeping-up, you would realize that Bartlomiej is upset
about our criticisms of the Ralink drivers in staging.  That would seem
to be the reason he has made himself such an irritant in linux-wireless
over the past few weeks.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Luis Correia]

[huge snip]

This is going to be my last reply to this thread (even if I get to be insulted).

I'm not a coder, I'm a tester and administrator for the rt2x00 project.
I'm not happy about the current state of the rt2x00 in-kernel drivers.
I tend to agree that more could be done.

Even though I'm not a coder, I could be hipotetically responsable for
the current situation. It is my job function to motivate people to
work on the rt2x00 in-kernel drivers, but apparently I've failed here.
It's not an atitude problem, as some have suggested, it's just life.

About Bartlomiej, there is only one more thing that I'll say:

I've searched on my GMail archives and the only patch Bart has
provided so far for the rt2x00 project is this:

[PATCH] MAINTAINERS: rt2x00 list is moderated

Which, while technically correct, adds nothing to the project.

So, I will personally continue to ignore Bart's comments, regards and
rants, until he provides patches for rt2x00 that actually make the
driver better.

Luis Correia
rt2x00 project admin,
(but not writing this email as an official project statement)

Re: pull request: wireless-next-2.6 2009-10-28

[Randy Dunlap]

Luis Correia wrote:
> [huge snip]
> 
> This is going to be my last reply to this thread (even if I get to be insulted).
> 
> I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> I'm not happy about the current state of the rt2x00 in-kernel drivers.
> I tend to agree that more could be done.
> 
> Even though I'm not a coder, I could be hipotetically responsable for
> the current situation. It is my job function to motivate people to
> work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> It's not an atitude problem, as some have suggested, it's just life.
> 
> About Bartlomiej, there is only one more thing that I'll say:
> 
> I've searched on my GMail archives and the only patch Bart has
> provided so far for the rt2x00 project is this:
> 
> [PATCH] MAINTAINERS: rt2x00 list is moderated
> 
> Which, while technically correct, adds nothing to the project.

whatever.  That patch still needs to be applied.

> So, I will personally continue to ignore Bart's comments, regards and
> rants, until he provides patches for rt2x00 that actually make the
> driver better.
> 
> Luis Correia
> rt2x00 project admin,
> (but not writing this email as an official project statement)


-- 
~Randy

Re: pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

On Mon, Nov 02, 2009 at 09:36:20AM -0800, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> > 
> > This is going to be my last reply to this thread (even if I get to be insulted).
> > 
> > I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> > I'm not happy about the current state of the rt2x00 in-kernel drivers.
> > I tend to agree that more could be done.
> > 
> > Even though I'm not a coder, I could be hipotetically responsable for
> > the current situation. It is my job function to motivate people to
> > work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> > It's not an atitude problem, as some have suggested, it's just life.
> > 
> > About Bartlomiej, there is only one more thing that I'll say:
> > 
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> > 
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> > 
> > Which, while technically correct, adds nothing to the project.
> 
> whatever.  That patch still needs to be applied.

And, in fact, it has been...already in linux-2.6:

	commit b5654f5e7fc414a6e69b3647db2b043257c9e62e
	Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
	Date:   Mon Oct 26 16:49:50 2009 -0700

	MAINTAINERS: rt2x00 list is moderated

	Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Hth...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

On Mon, Nov 02, 2009 at 09:36:20AM -0800, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> > 
> > This is going to be my last reply to this thread (even if I get to be insulted).
> > 
> > I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> > I'm not happy about the current state of the rt2x00 in-kernel drivers.
> > I tend to agree that more could be done.
> > 
> > Even though I'm not a coder, I could be hipotetically responsable for
> > the current situation. It is my job function to motivate people to
> > work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> > It's not an atitude problem, as some have suggested, it's just life.
> > 
> > About Bartlomiej, there is only one more thing that I'll say:
> > 
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> > 
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> > 
> > Which, while technically correct, adds nothing to the project.
> 
> whatever.  That patch still needs to be applied.

And, in fact, it has been...already in linux-2.6:

	commit b5654f5e7fc414a6e69b3647db2b043257c9e62e
	Author: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
	Date:   Mon Oct 26 16:49:50 2009 -0700

	MAINTAINERS: rt2x00 list is moderated

	Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
	Signed-off-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
	Signed-off-by: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>

Hth...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Ivo van Doorn]

Well and then another rt2x00 developer discovered this nice little
fight about rt2x00 on the mailinglists...

First for the record, because at the start people where talking about the
maintainership of rt2x00, one thing needs to be straight:

As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
drivers/net/wireless/rt2x00 folder.

At this time I am hold the position within the rt2x00 team which is making the
decisions about the rt2x00 code and design.
I am also the one that is (N)Acks the patches from others when they are send
to the rt2x00-users or linux-wireless mailinglist.

As for my behavior in discussions:

I am doing my best to listen to all complains regarding the rt2x00 code and design and
improve it if the complainer has a valid point. However, obviously I can disagree with
the complainer and in that case I will explain to that person _why_ I disagree. It is up
to the complainer to convince me that he is right, agree with my response, or whine.

Now as for more specific responses:

On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> rt2800 drivers have their maintainers and I would like to know what they
> are doing besides complaining about users and staging tree..

Working for Avanade, Zarafa and as freelancer for Linux Magazine.
But I guess you mean rt2x00 specific work?
Well that list consists of:
 - Listening to people complain
 - Responding to those people, because otherwise they complain that they are being ignored.
 - Following bug reports, and request testing or additional information if required
 - Bugfixing
 - Reviewing patches from contributors
 - Applying patches from contributors
 - Discussing improvements over patches from contributors

Well nothing of this list should be new to you, but apparently you needed some confirmation.

On Thursday 29 October 2009, Johannes Berg wrote:
> On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> 
> > In case you're concerned, I actually agree with John and others
> > on this issue, and disagree with your position.
> 
> In this particular case, I think it makes more sense to duplicate the
> code _especially_ because it's not working yet. That frees people
> hacking on it of having to worry about breaking other devices.

Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
in the previous discussion.

On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..

Your code review comments were commented upon with my reasons
why this code duplication exists. I even admitted that when the time is
ready I will remove the code duplication.

On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.

The review concerns regarding the duplicate code would only reduce the
amount of code. It would not magically fix bugs (at least the chance of that
would be quite small).

So far rt2800usb performs better then rt2800pci, and the difference gets
only bigger when I use the exact same register initialization from rt2800usb
in rt2800pci.

But Bartjmoiej knows that the register initialization can be exactly the same,
from his experience with the staging drivers.
So far hasn't been interested in sharing the knowledge in what must be
changed in rt2800pci/usb to make them both work with the same register
initialization.

On Monday 02 November 2009, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> > 
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> > 
> > Which, while technically correct, adds nothing to the project.
> 
> whatever.  That patch still needs to be applied.

And I haven't seen anybody stating the opposite...

Ivo

Re: pull request: wireless-next-2.6 2009-10-28

[Ivo van Doorn]

Well and then another rt2x00 developer discovered this nice little
fight about rt2x00 on the mailinglists...

First for the record, because at the start people where talking about the
maintainership of rt2x00, one thing needs to be straight:

As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
drivers/net/wireless/rt2x00 folder.

At this time I am hold the position within the rt2x00 team which is making the
decisions about the rt2x00 code and design.
I am also the one that is (N)Acks the patches from others when they are send
to the rt2x00-users or linux-wireless mailinglist.

As for my behavior in discussions:

I am doing my best to listen to all complains regarding the rt2x00 code and design and
improve it if the complainer has a valid point. However, obviously I can disagree with
the complainer and in that case I will explain to that person _why_ I disagree. It is up
to the complainer to convince me that he is right, agree with my response, or whine.

Now as for more specific responses:

On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> rt2800 drivers have their maintainers and I would like to know what they
> are doing besides complaining about users and staging tree..

Working for Avanade, Zarafa and as freelancer for Linux Magazine.
But I guess you mean rt2x00 specific work?
Well that list consists of:
 - Listening to people complain
 - Responding to those people, because otherwise they complain that they are being ignored.
 - Following bug reports, and request testing or additional information if required
 - Bugfixing
 - Reviewing patches from contributors
 - Applying patches from contributors
 - Discussing improvements over patches from contributors

Well nothing of this list should be new to you, but apparently you needed some confirmation.

On Thursday 29 October 2009, Johannes Berg wrote:
> On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> 
> > In case you're concerned, I actually agree with John and others
> > on this issue, and disagree with your position.
> 
> In this particular case, I think it makes more sense to duplicate the
> code _especially_ because it's not working yet. That frees people
> hacking on it of having to worry about breaking other devices.

Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
in the previous discussion.

On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..

Your code review comments were commented upon with my reasons
why this code duplication exists. I even admitted that when the time is
ready I will remove the code duplication.

On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.

The review concerns regarding the duplicate code would only reduce the
amount of code. It would not magically fix bugs (at least the chance of that
would be quite small).

So far rt2800usb performs better then rt2800pci, and the difference gets
only bigger when I use the exact same register initialization from rt2800usb
in rt2800pci.

But Bartjmoiej knows that the register initialization can be exactly the same,
from his experience with the staging drivers.
So far hasn't been interested in sharing the knowledge in what must be
changed in rt2800pci/usb to make them both work with the same register
initialization.

On Monday 02 November 2009, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> > 
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> > 
> > Which, while technically correct, adds nothing to the project.
> 
> whatever.  That patch still needs to be applied.

And I haven't seen anybody stating the opposite...

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Pavel Machek]

> About Bartlomiej, there is only one more thing that I'll say:
> 
> I've searched on my GMail archives and the only patch Bart has
> provided so far for the rt2x00 project is this:
> 
> [PATCH] MAINTAINERS: rt2x00 list is moderated
> 
> Which, while technically correct, adds nothing to the project.
> 
> So, I will personally continue to ignore Bart's comments, regards and
> rants, until he provides patches for rt2x00 that actually make the
> driver better.

Well, he provided review feedback... he should be thanked for that,
not flamed for it.
									Pavel  

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Monday 02 November 2009 19:43:10 Ivo van Doorn wrote:
> Well and then another rt2x00 developer discovered this nice little
> fight about rt2x00 on the mailinglists...
> 
> First for the record, because at the start people where talking about the
> maintainership of rt2x00, one thing needs to be straight:
> 
> As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
> for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
> drivers/net/wireless/rt2x00 folder.
> 
> At this time I am hold the position within the rt2x00 team which is making the
> decisions about the rt2x00 code and design.

rt2x00 doesn't "own" Linux Ralink support, ditto for rt2800 drivers.

This is not how things work here, sorry.

> I am also the one that is (N)Acks the patches from others when they are send
> to the rt2x00-users or linux-wireless mailinglist.

If you are not willing to stand behind your own patches, how do you expect
others to trust your judgment?

> As for my behavior in discussions:
> 
> I am doing my best to listen to all complains regarding the rt2x00 code and design and
> improve it if the complainer has a valid point. However, obviously I can disagree with
> the complainer and in that case I will explain to that person _why_ I disagree. It is up
> to the complainer to convince me that he is right, agree with my response, or whine.
> 
> Now as for more specific responses:
> 
> On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > rt2800 drivers have their maintainers and I would like to know what they
> > are doing besides complaining about users and staging tree..
> 
> Working for Avanade, Zarafa and as freelancer for Linux Magazine.
> But I guess you mean rt2x00 specific work?
> Well that list consists of:
>  - Listening to people complain
>  - Responding to those people, because otherwise they complain that they are being ignored.
>  - Following bug reports, and request testing or additional information if required
>  - Bugfixing
>  - Reviewing patches from contributors
>  - Applying patches from contributors
>  - Discussing improvements over patches from contributors
> 
> Well nothing of this list should be new to you, but apparently you needed some confirmation.

I meant rt2800 support specifically, sorry if this was not clear.

The work on rt2800 drivers was started in the beginning of 2008 and after
few months you were already behind deadlines that you had set yourself:

	http://markmail.org/message/a753dws6tqytb3a4

During almost two years rt2x00 project didn't manage to produce working
support for rt2800..  in the meantime the world has moved on and we have
another chipset generation (rt30x0) to worry about, and also rt33xx one
on the horizon..

> On Thursday 29 October 2009, Johannes Berg wrote:
> > On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> > 
> > > In case you're concerned, I actually agree with John and others
> > > on this issue, and disagree with your position.
> > 
> > In this particular case, I think it makes more sense to duplicate the
> > code _especially_ because it's not working yet. That frees people
> > hacking on it of having to worry about breaking other devices.
> 
> Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
> in the previous discussion.

Nope, it just adds needles development/maintenance burden since it will
make people lose fixes already applied to the working code, please see my
other mail.

> On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > I find it rather disappointing that all my review comments regarding
> > rt2800pci support were just completely ignored and then the initial
> > patch was merged just as it was..
> 
> Your code review comments were commented upon with my reasons
> why this code duplication exists. I even admitted that when the time is
> ready I will remove the code duplication.

The right time was two years ago when you were starting working on those
drivers.  IOW It shouldn't have happened in the first place.

I also have serious questions about transparency of the process and cannot
understand why it takes so long for the code to be pushed upstream.

commit 1761631 -- obvious bugfix and I'm pretty sure I've seen it in rt2x00
tree back in September (you're re-basing rt2x00 tree at random moments so it
is impossible to track the status of patches that you are handling).

rt2800pci patch itself has been getting dust in your tree since at least
April (it hasn't received any bigger updates since then)..

> On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > Quite the contrary, I'm pretty confident that addressing my review concerns
> > would result in better RT28x00 / RT30x0 support in the very near future.
> 
> The review concerns regarding the duplicate code would only reduce the
> amount of code. It would not magically fix bugs (at least the chance of that
> would be quite small).

Please see my other mail.

> So far rt2800usb performs better then rt2800pci, and the difference gets
> only bigger when I use the exact same register initialization from rt2800usb
> in rt2800pci.
> 
> But Bartjmoiej knows that the register initialization can be exactly the same,
> from his experience with the staging drivers.
> So far hasn't been interested in sharing the knowledge in what must be
> changed in rt2800pci/usb to make them both work with the same register
> initialization.

The knowledge is all in your local copy of linux-next (I don't memorize
things like chipset initialization sequences) and in the review comments
that you have happily dismissed.

-- 
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Ivo van Doorn]

On Tuesday 03 November 2009, Bartlomiej Zolnierkiewicz wrote:
> On Monday 02 November 2009 19:43:10 Ivo van Doorn wrote:
> > Well and then another rt2x00 developer discovered this nice little
> > fight about rt2x00 on the mailinglists...
> > 
> > First for the record, because at the start people where talking about the
> > maintainership of rt2x00, one thing needs to be straight:
> > 
> > As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
> > for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
> > drivers/net/wireless/rt2x00 folder.
> > 
> > At this time I am hold the position within the rt2x00 team which is making the
> > decisions about the rt2x00 code and design.
> 
> rt2x00 doesn't "own" Linux Ralink support, ditto for rt2800 drivers.

You really have problems reading mails, haven't you? Or at least you
only want to read what you want to read...

Please READ the paragraph again.
 
I will highlight the thing again:
"about the rt2x00 code and design"

I am not talking about Ralink support I am talking about RT2X00 support.

If you feel that the maintainer of a particular driver has no say about the driver
he wrote himself, then I am not seeing the point of having maintainers. We can
then all just randomly hack in all drivers without any form of structure.

> > I am also the one that is (N)Acks the patches from others when they are send
> > to the rt2x00-users or linux-wireless mailinglist.
> 
> If you are not willing to stand behind your own patches, how do you expect
> others to trust your judgment?

Ehm, please explain? I am sending patches upstream, but apparently I don't stand behind them?
Then why the f*** am I sending them?

> > As for my behavior in discussions:
> > 
> > I am doing my best to listen to all complains regarding the rt2x00 code and design and
> > improve it if the complainer has a valid point. However, obviously I can disagree with
> > the complainer and in that case I will explain to that person _why_ I disagree. It is up
> > to the complainer to convince me that he is right, agree with my response, or whine.
> > 
> > Now as for more specific responses:
> > 
> > On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > rt2800 drivers have their maintainers and I would like to know what they
> > > are doing besides complaining about users and staging tree..
> > 
> > Working for Avanade, Zarafa and as freelancer for Linux Magazine.
> > But I guess you mean rt2x00 specific work?
> > Well that list consists of:
> >  - Listening to people complain
> >  - Responding to those people, because otherwise they complain that they are being ignored.
> >  - Following bug reports, and request testing or additional information if required
> >  - Bugfixing
> >  - Reviewing patches from contributors
> >  - Applying patches from contributors
> >  - Discussing improvements over patches from contributors
> > 
> > Well nothing of this list should be new to you, but apparently you needed some confirmation.
> 
> I meant rt2800 support specifically, sorry if this was not clear.
> 
> The work on rt2800 drivers was started in the beginning of 2008 and after
> few months you were already behind deadlines that you had set yourself:
> 
> 	http://markmail.org/message/a753dws6tqytb3a4
> 
> During almost two years rt2x00 project didn't manage to produce working
> support for rt2800..  in the meantime the world has moved on and we have
> another chipset generation (rt30x0) to worry about, and also rt33xx one
> on the horizon..

And thank you for your valuable effort in assisting in the driver development
during those 2 years. I am really happy about people looking from the sideline
and complaining things are not moving as fast as they would like it.
If you cared about the slow progress, then you had the past 2 years to help out,
but apparently that is too much to ask. Unfortunately a lot of people think like
you, which means that during those 2 years dozens of people have complained
about the lack of progress without any of them helping out (and I am not talking
about users only, I am also talking about people who have programming skills).

If you look at the Signed-off list of the rt2800pci/usb patches you will see that
only a handfull of people actually helped.

> > On Thursday 29 October 2009, Johannes Berg wrote:
> > > On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> > > 
> > > > In case you're concerned, I actually agree with John and others
> > > > on this issue, and disagree with your position.
> > > 
> > > In this particular case, I think it makes more sense to duplicate the
> > > code _especially_ because it's not working yet. That frees people
> > > hacking on it of having to worry about breaking other devices.t initialization sequences) and in the review 
> > 
> > Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
> > in the previous discussion.
> 
> Nope, it just adds needles development/maintenance burden since it will
> make people lose fixes already applied to the working code, please see my
> other mail.

As mentioned in my mail, there were differences in the drivers during development,
and I had a working rt2800usb driver as base. But with the same settings the rt2800pci
couldn't get to work.

With the merged drivers you would constantly need to check if it works for rt2800pci,
but also if you haven't broken rt2800usb in the meantime. This way rt2800usb was
able to be merged months before rt2800pci because there was no common code.

Once both drivers are solid working, then there are no problems with merging them,
I wonder how many times I have to repeat that...

> > On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > I find it rather disappointing that all my review comments regarding
> > > rt2800pci support were just completely ignored and then the initial
> > > patch was merged just as it was..
> > 
> > Your code review comments were commented upon with my reasons
> > why this code duplication exists. I even admitted that when the time is
> > ready I will remove the code duplication.
> 
> The right time was two years ago when you were starting working on those
> drivers.  IOW It shouldn't have happened in the first place.

Please see my other mail, please read my above comment, and thank you again
for participating in the rt2800 development of those 2 years.

> I also have serious questions about transparency of the process and cannot
> understand why it takes so long for the code to be pushed upstream.

So you start looking now, and complain you can't see the process of the last 2 years?
There have been dozens of status reports regarding rt2800, and the number of responses
in general have always been limited.

But now I reread that last sentence, you are complaining that rt2800pci wasn't pushed
upstream earlier? While this whole discussion is about that merging rt2800pci was a bad
idea?

> commit 1761631 -- obvious bugfix and I'm pretty sure I've seen it in rt2x00
> tree back in September (you're re-basing rt2x00 tree at random moments so it
> is impossible to track the status of patches that you are handling).

I'm missing the point here.

> rt2800pci patch itself has been getting dust in your tree since at least
> April (it hasn't received any bigger updates since then)..

And how many times do I have to repeat the reason?
I think that after dozens of mails, the message should have been clear, especially
to somebody who apparently has been monitoring and worrying about the development
process for the last 2 years....

> > On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > Quite the contrary, I'm pretty confident that addressing my review concerns
> > > would result in better RT28x00 / RT30x0 support in the very near future.
> > 
> > The review concerns regarding the duplicate code would only reduce the
> > amount of code. It would not magically fix bugs (at least the chance of that
> > would be quite small).
> 
> Please see my other mail.

And did your patches make rt2800pci work better?
Does rt2800usb suddenly work for 11n networks?

> > So far rt2800usb performs better then rt2800pci, and the difference gets
> > only bigger when I use the exact same register initialization from rt2800usb
> > in rt2800pci.
> > 
> > But Bartjmoiej knows that the register initialization can be exactly the same,
> > from his experience with the staging drivers.
> > So far hasn't been interested in sharing the knowledge in what must be
> > changed in rt2800pci/usb to make them both work with the same register
> > initialization.
> 
> The knowledge is all in your local copy of linux-next (I don't memorize
> things like chipset initialization sequences) and in the review comments
> that you have happily dismissed.

Your review comments were regarding _moving_ code to a generic stack
for rt2800pci and rt2800usb while I already indicated that would not improve
the status of rt2800pci (instead it would make it worse, since I already tested
if those settings would work). But apparently merging the code is better then
fixing the code.

Ivo

Re: pull request: wireless-next-2.6 2009-10-28

[Bartlomiej Zolnierkiewicz]

On Tuesday 03 November 2009 21:32:30 Ivo van Doorn wrote:

> > rt2800pci patch itself has been getting dust in your tree since at least
> > April (it hasn't received any bigger updates since then)..
> 
> And how many times do I have to repeat the reason?
> I think that after dozens of mails, the message should have been clear, especially
> to somebody who apparently has been monitoring and worrying about the development
> process for the last 2 years....

Just for the record:

I got only interested in rt2x00 support around April this year (while I was
doing major staging cleanups everywhere) and I was hearing back then that
rt2800pci will be merged "really soon" and that the project is making "great
progress"..

-- 
Bartlomiej Zolnierkiewicz

Re: pull request: wireless-next-2.6 2009-10-28

[Jiri Kosina]

On Mon, 2 Nov 2009, Pavel Machek wrote:

> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> > 
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> > 
> > Which, while technically correct, adds nothing to the project.
> > 
> > So, I will personally continue to ignore Bart's comments, regards and
> > rants, until he provides patches for rt2x00 that actually make the
> > driver better.
> 
> Well, he provided review feedback... he should be thanked for that,
> not flamed for it.

He has actually written real patches (and quite non-trivial both in amount 
and in functionality), see

	http://lkml.org/lkml/2009/11/3/372

But yes, he got flamed for this for some odd reason. I got the impression 
that the community around rt2x00 doesn't like (or understand) the way how 
opensource development happens.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: pull request: wireless-next-2.6 2009-10-28

[Ivo van Doorn]

On Wednesday 04 November 2009, Jiri Kosina wrote:
> On Mon, 2 Nov 2009, Pavel Machek wrote:
> 
> > > I've searched on my GMail archives and the only patch Bart has
> > > provided so far for the rt2x00 project is this:
> > > 
> > > [PATCH] MAINTAINERS: rt2x00 list is moderated
> > > 
> > > Which, while technically correct, adds nothing to the project.
> > > 
> > > So, I will personally continue to ignore Bart's comments, regards and
> > > rants, until he provides patches for rt2x00 that actually make the
> > > driver better.
> > 
> > Well, he provided review feedback... he should be thanked for that,
> > not flamed for it.
> 
> He has actually written real patches (and quite non-trivial both in amount 
> and in functionality), see
> 
> 	http://lkml.org/lkml/2009/11/3/372

Please look at the TIMESTAMP of the mail you refer to, and the TIMESTAMP
of the mail from Luis. And then you can make assumptions about the text...

> But yes, he got flamed for this for some odd reason. I got the impression 
> that the community around rt2x00 doesn't like (or understand) the way how 
> opensource development happens.

Well you mean the open source development where non-contributors
complain that the contributors work too slowly? Well if that is the way
things should go, then I don't want to be part of such idiocy. Perhaps
that is the policy in some companies which try to import it into the
Open Source world...

Ivo

Re: pull request: wireless-next-2.6 2009-10-28

[Ivo van Doorn]

On Wednesday 04 November 2009, Jiri Kosina wrote:
> On Mon, 2 Nov 2009, Pavel Machek wrote:
> 
> > > I've searched on my GMail archives and the only patch Bart has
> > > provided so far for the rt2x00 project is this:
> > > 
> > > [PATCH] MAINTAINERS: rt2x00 list is moderated
> > > 
> > > Which, while technically correct, adds nothing to the project.
> > > 
> > > So, I will personally continue to ignore Bart's comments, regards and
> > > rants, until he provides patches for rt2x00 that actually make the
> > > driver better.
> > 
> > Well, he provided review feedback... he should be thanked for that,
> > not flamed for it.
> 
> He has actually written real patches (and quite non-trivial both in amount 
> and in functionality), see
> 
> 	http://lkml.org/lkml/2009/11/3/372

Please look at the TIMESTAMP of the mail you refer to, and the TIMESTAMP
of the mail from Luis. And then you can make assumptions about the text...

> But yes, he got flamed for this for some odd reason. I got the impression 
> that the community around rt2x00 doesn't like (or understand) the way how 
> opensource development happens.

Well you mean the open source development where non-contributors
complain that the contributors work too slowly? Well if that is the way
things should go, then I don't want to be part of such idiocy. Perhaps
that is the policy in some companies which try to import it into the
Open Source world...

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: wireless-next-2.6 2009-10-28

[Pavel Machek]

> > But yes, he got flamed for this for some odd reason. I got the impression 
> > that the community around rt2x00 doesn't like (or understand) the way how 
> > opensource development happens.
> 
> Well you mean the open source development where non-contributors
> complain that the contributors work too slowly? 

This was the case when non-contributor complained that patch adds
2KLoC of unneccessary code.

> Perhaps
> that is the policy in some companies which try to import it into the
> Open Source world...

Do you really have to attack everyone around?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pull request: wireless-next-2.6 2009-10-28

[John W. Linville]

On Wed, Nov 04, 2009 at 11:00:25PM +0100, Pavel Machek wrote:
> > > But yes, he got flamed for this for some odd reason. I got the impression 
> > > that the community around rt2x00 doesn't like (or understand) the way how 
> > > opensource development happens.
> > 
> > Well you mean the open source development where non-contributors
> > complain that the contributors work too slowly? 
> 
> This was the case when non-contributor complained that patch adds
> 2KLoC of unneccessary code.
> 
> > Perhaps
> > that is the policy in some companies which try to import it into the
> > Open Source world...
> 
> Do you really have to attack everyone around?

Really, this is enough.

It seems clear that neither side of this debate sees or appreciates
the injuries that the other side claims.  In any case, there seems
little good can come from continuing this bickering.

Now that Bart is posting patches and the rt2x00 team is actively
reviewing (and mostly Acking) them, I hope everyone can just BACK
THE HELL OFF and let the process work itself out.

Please let this discussion end.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.