"David S. Miller" <[email protected]> writes:
> From: Donald Becker <[email protected]>
> Date: Fri, 13 Dec 2002 11:56:17 -0500 (EST)
>
> The development criteria used to be technically based, and that is still
> the public statement. Now, as your statement makes clear, working code
> is an irrelevant criteria.
>No, working code is only part of the equation. If you're a total and
>complete asshole, your work is likely to get lost to the sands of
>time. In such a case nobody wants to deal with you.
The IDE code and one of its current maintainers disproves your point.
I did notice that it was you and not Donald who started using swear
words. Ego problem?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
<<Interfaces should NEVER change in patch level versions.
Just *DO NOT DO IT*.
>>I do agree on this.
This is a common complaint about linux kernel developers. And this always gives an insecure feeling :-) for the device driver or kernel module programmers.
This was one of the issues in my earlier company/work and they have gone for another OS.
Warm Regards
Arun
"Michael Richardson" wrote:
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Donald" == Donald Becker writes:
Donald> The drivers in the kernel are now heavily modified and have significantly
Donald> diverged from my version. Sure, you are fine with having someone else
Donald> do the difficult and unrewarding debugging and maintainence work, while
Donald> you work on just the latest cool hardware, change the interfaces and are
Donald> concerned only with the current kernel version.
I agree strongly with Donald.
Interfaces should NEVER change in patch level versions.
Just *DO NOT DO IT*.
Go wild in odd-numbered.. get the interfaces right there.
But leave them alone afterward.
This is a fundamental tenant of being professional. Otherwise, the kernel
people are the biggest reason I've ever seen for using *BSD.
Microsoft is not the real enemy. Gratuitous change is.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] [email protected] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy the best in Movies at http://www.videos.indiatimes.com
Change the way you talk. Indiatimes presents Valufon, Your PC to Phone service with clear voice at rates far less than the normal ISD rates. Go to http://www.valufon.indiatimes.com. Choose your plan. BUY NOW.
On Sat, Dec 14, 2002 at 08:05:30PM +0530, arun4linux wrote:
> Interfaces should NEVER change in patch level versions.
> Just *DO NOT DO IT*.
> I do agree on this.
Rubbish.
Think about what you've just said. Patch level version changes are
things like 2.5.43 to 2.5.44 or 2.4.19 to 2.4.20.
You are saying that we shouldn't change any interfaces between (eg)
2.5.43 and 2.5.44, but we should change every interface we want to
change between 2.4.15 and 2.5.0.
This is obviously completely bogus. 2.5 is a _development_ tree.
Everyone should expect anything, including interfaces to change
between each development patch level.
> This is a common complaint about linux kernel developers. And this always
> gives an insecure feeling :-) for the device driver or kernel module
> programmers.
If interfaces are changed without extremely good reason between two
_stable_ patch level versions, that would be a bug.
> This was one of the issues in my earlier company/work and they have
> gone for another OS.
Was the problem against a stable kernel version? Did you report the
problem when you found it? Was there a response?
Unless you have done at least the above, I, for one, have very little
sympathy.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sat, 14 Dec 2002, Russell King wrote:
...
> Rubbish.
>
> Think about what you've just said. Patch level version changes are
> things like 2.5.43 to 2.5.44 or 2.4.19 to 2.4.20.
>
> You are saying that we shouldn't change any interfaces between (eg)
> 2.5.43 and 2.5.44, but we should change every interface we want to
> change between 2.4.15 and 2.5.0.
Put very simply yes . x.odd-number.y IS for DEVELOPEMENT ,
x.even-number.y IS for Stability .
If people can not understand that I feel sorry for them .
JimL
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
On Sat, 14 Dec 2002, Russell King wrote:
> On Sat, Dec 14, 2002 at 08:05:30PM +0530, arun4linux wrote:
> > Interfaces should NEVER change in patch level versions.
> > Just *DO NOT DO IT*.
> > I do agree on this.
>
> Rubbish.
>
> Think about what you've just said. Patch level version changes are
> things like 2.5.43 to 2.5.44 or 2.4.19 to 2.4.20.
>
> You are saying that we shouldn't change any interfaces between (eg)
> 2.5.43 and 2.5.44, but we should change every interface we want to
> change between 2.4.15 and 2.5.0.
>
> This is obviously completely bogus. 2.5 is a _development_ tree.
> Everyone should expect anything, including interfaces to change
> between each development patch level.
>
> > This is a common complaint about linux kernel developers. And this always
> > gives an insecure feeling :-) for the device driver or kernel module
> > programmers.
>
> If interfaces are changed without extremely good reason between two
> _stable_ patch level versions, that would be a bug.
>
There have been a few during 2.4... The alloc_kiovec stuff for instance
and zap_page_range. 2.2 was much more stable.
Interface changes in development series is (or atleast should be to
everyone using linux) a known "feature".
Regards,
--
Steffen Persvold | Scali AS
mailto:[email protected] | http://www.scali.com
Tel: (+47) 2262 8950 | Olaf Helsets vei 6
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY
Hi,
A good scheme for numbering kernels or software components in general is
as follows
For stable releases. (x.even.y=major.minor.patch)
increment patch for any bug fixes.
increment minor for any enhancements or new interfaces.
increment major for interface changes or interface deletions.(dangerous
or poor design)
We should increment major even if interface remains same but behaviour
has changed.(again may be poor design)
For development releases we can't follow the above scheme, because the
interfaces are in a flux and we may end up
in version 589.201.700 from 2.4.20. So, we decide to increment patch
number for all changes and deletions.
Hope it helps!
Regards
Aravind
--
http://fastmail.fm - IMAP accessible web-mail
As if this wasn't contentious enough already, let me throw out something
for your consideration.
Q: When are *developers* most in need of stable models?
A: During development.
There's a fundamental problem here. Developers want complete freedom to
change their own models whenever they feel the need, yet the models on
which they depend must remain stable if their development is to continue
without interruption and they get snarly when those models change.
--
Mark H. Wood, Lead System Programmer [email protected]
MS Windows *is* user-friendly, but only for certain values of "user".