Linux-kernel mailing list archive 2000-32,: Re: Definitions

# Re: Definitions

Michael W Zappe (zapman@interlan.net)
Mon, 7 Aug 2000 14:28:38 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Matthew Wilcox: "Re: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128?"
- Previous message: Rogier Wolff: "Re: Adaptec 2930U2 problem followup"

On Mon, Aug 07, 2000 at 06:33:09PM +0200, Simon Richter wrote:
> On Mon, 7 Aug 2000, Michael W Zappe wrote:
>
> > One interesting aspect to linux development that I've seen is a large
> > amount of dialogue*, but a lack of common definitions. I was
> > wondering if anyone would care to define what consitutes a 'feature'
> > in contrast to a 'bug fix' when it comes to the linux kernel.
> > Specific definitions could really help new contributers to the kernel,
> > rather than the rather arbitrary standards that are being applied now.
>
> Perhaps the best definition I've seen is that a feature is something you
> can turn off (contrary to a bug). A bug fix is something that takes a bug
> and either removes it or turns it into a feature.
>
> Simon
>
> --
> PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
> Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1
> Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

By this definition, however, the scheduler and virtual memory manager are bugs. So it's not really a useful definition. It would also make feature freezes pointless, since features can be disabled and won't affect everyone, whilst bug fixes should be heavily controled since they affect everyone.

As an exercise to help make Linux development less crazy, coming up with REAL definitions (not trite sayings) and removing the seeming arbitrariness in designation would be nice. Not neccicarily making rigid, unchanging policies, but a guideline that people can write to, and know what to expect from a feature freeze. In 'normal' software development, a feature freeze usually means that APIs don't change, and entirely new filesystems don't appear...

Mike

----------------------------------------------
Michael Zappe <zapman@interlan.net>

Chief Architect, Filesystems
Interlan Communications
111 Corning Drive
Cary, NC 27511

"The sorcerer is a Simple Realist: the world
is real--but then so must consciousness be real
since its effects are so tangible. The dullard
finds even wine tasteless but the sorcerer can be
intoxicated by the mere sight of water."
--Hakim Bey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Matthew Wilcox: "Re: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128?"
- Previous message: Rogier Wolff: "Re: Adaptec 2930U2 problem followup"