On Mon, 7 Aug 2000, Michael W Zappe wrote:
["feature" vs. "bug"]
> > 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.
> By this definition, however, the scheduler and virtual memory manager
> are bugs.
Yes and no. Yes because there is no config option for that (may be useful
on embedded systems), no because there is general consensus that this is
not a bug. :-)
> So it's not really a useful definition.
It works for the "bug fix" vs. "new feature" question, which seems to be
the reason for this thread.
> 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.
Feature freezes actually are pointless for that reason. The only thing to
check when adding new features is whether they really have no effect on
the generated code when turned off.
> Not neccicarily making rigid, unchanging policies, but a guideline
> that people can write to, and know what to expect from a feature
> freeze.
Well, I would expect that code that is supposed to be stable (not marked
as "EXPERIMENTAL") doesn't change except when bugs are removed, so that at
the end of the feature freeze the end user can expect that these drivers
have reached a certain level of stability. IMO the "Ask for
experimental/incomplete drivers" switch is there for exactly this reason
(feature freezing incomplete drivers is senseless).
> In 'normal' software development, a feature freeze usually means that
> APIs don't change, and entirely new filesystems don't appear...
APIs should change (if at all) when all the features that were delayed by
a feature freeze are added into the next version. A feature freeze is no
reason not to add a new filesystem, provided it stays in its own
subdirectory and is marked as EXPERIMENTAL.
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:14 EST