netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ieee80211 updates
       [not found]         ` <20050919004450.16m2d1hn7les0o00@www.sourmilk.net>
@ 2005-09-19  5:41           ` Jeff Garzik
  2005-09-19 22:00             ` Matt Domsch
  0 siblings, 1 reply; 2+ messages in thread
From: Jeff Garzik @ 2005-09-19  5:41 UTC (permalink / raw)
  To: Michael Wu
  Cc: Christoph Hellwig, James Ketrenos, NetDev, ieee80211-devel,
	Andrew Morton, Linux Kernel

Michael Wu wrote:
> If it has a version, then only the maintainer can submit patches - 

False.  Presence of an optional label in source code files does not 
change the fundamental rules of open source, or the processes 
surrounding patch merging in the Linux kernel.  Anybody who feels the 
version number should be changed is welcome to submit a patch.  And a 
reviewer along the line is welcome to reject such a patch, if they think 
it is unwarranted.


> otherwise the
> version is useless for identifying what code you're running. (unless other

False.  We have plenty of examples of slower-moving drivers where 
community consensus often dictates a version number change.


> submitters decide to alter the version too, which is probably not a good 
> idea)

For any given driver/subsystem/whatever version number in the kernel, 
ultimately a submittor changes the version and one or more reviewers 
approve this, by pulling the change into their tree.  Your "probably not 
a good idea" is the 100% case here, including the master version number 
in ./Makefile.


>>> That early and often thing is true for drivers aswell, the intel 
>>> wireless
>>> driver are so hopelessly out of date in mainline just after 
>>> submission that
>>> it's not funny anymore.  Hopefully we'll have a mainline maintainer for
>>> them soon that imports everything important from intel and other 
>>> contributors.
>>
>>
>> Patience:  We still have over 20 patches to merge, before even getting
>> to the ipw updates.
>>
> I wish those patches were submitted and merged quickly when they were 
> created
> instead of piling up. Other people can't get patches merged because it 

Agreed.


> Other people can't get patches merged because it
> would
> break the chain of patches. Patches are being sent too late and 
> and infrequently.. 

Patience.  We've got to balance kernel hackers' insatiable desire for 
cleanups, with the desire of users and driver developers to move forward 
with Linux wireless support.

Since Intel has useful stuff, stuff which affects a wide range of 
hardware owned by Linux users, it's worth waiting a bit to let them 
catch up.  Of course, if it takes forever to merge their stuff, someone 
else will inevitably come along and speed up the process.  Open source 
at work.

Currently, it has rather been like a clock algorithm:  merge initial 
ieee80211 code from Intel.  Accept months worth of cleanups from 
community.  Accept unifying updates from Jouni.  Begin merging work from 
Jiri and SuSE.  Now the clock hand points at Intel again, and they've 
been waiting a while to send useful stuff.

People are slowly converging at a decent solution, while at the same 
moving wireless hardware support forward.  The need to improve the 
wireless API is balanced with the need to keep wireless hardware working 
(and/or enable new wireless hardware).

This convergence will be attained more rapidly once the community starts 
WORKING TOGETHER, rather than sending me competing patches.  Person A 
breaks Person B's work.  And then back again.

	Jeff

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: ieee80211 updates
  2005-09-19  5:41           ` ieee80211 updates Jeff Garzik
@ 2005-09-19 22:00             ` Matt Domsch
  0 siblings, 0 replies; 2+ messages in thread
From: Matt Domsch @ 2005-09-19 22:00 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Michael Wu, Christoph Hellwig, James Ketrenos, NetDev,
	ieee80211-devel, Andrew Morton, Linux Kernel

On Mon, Sep 19, 2005 at 01:41:14AM -0400, Jeff Garzik wrote:
> Michael Wu wrote:
> >If it has a version, then only the maintainer can submit patches - 
> 
> False.  Presence of an optional label in source code files does not 
> change the fundamental rules of open source, or the processes 
> surrounding patch merging in the Linux kernel.  Anybody who feels the 
> version number should be changed is welcome to submit a patch.  And a 
> reviewer along the line is welcome to reject such a patch, if they think 
> it is unwarranted.
> 
> >otherwise the
> >version is useless for identifying what code you're running. (unless other
> 
> False.  We have plenty of examples of slower-moving drivers where 
> community consensus often dictates a version number change.


This is also the reason for the 'srcversion' field available in
modinfo.  This is a CRC across the source code for a given module (not
counting #include<*>, but counting #include "*").  The version field
may not change, but if anything really cares about a particular source
code copy, and that it hasn't been patched, but the version field not
updated, they can see that.

Thanks to Rusty for implementing this.

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-09-19 22:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <4327625D.10808@linux.intel.com>
     [not found] ` <20050914105409.GB30645@infradead.org>
     [not found]   ` <43285ADF.5030506@linux.intel.com>
     [not found]     ` <20050917092846.GA14083@infradead.org>
     [not found]       ` <432E1069.8010102@pobox.com>
     [not found]         ` <20050919004450.16m2d1hn7les0o00@www.sourmilk.net>
2005-09-19  5:41           ` ieee80211 updates Jeff Garzik
2005-09-19 22:00             ` Matt Domsch

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).