Deleting parameters.

[Gerald (Jerry) Carter]

On Sat, 10 Nov 2001, Sean Elble wrote:

> Maybe Tridge would disagree with you, but I'm with him
> on this one. :-) There will always be unused/stupid,
> and even dangerous options in a program, and it is up
> to the both the users and developers to realize that.
> Options that aren't done right should be done right,
> and users should _know_ what options in _their_
> configuration files do what. My recommendation would

I think that certain things like "read only", "writeable"
and "writable" are candidates for reduction (to a single parameter.
But only after significant warning.  And only after
examining the consequences.

Think this out for a second.  Suppose we want to do away with
"writeable" and "writable" in Samba 3.0.  We must flag these
as deprecated beginning in the next 2.2.x release.
No consider what would happen if an admin still contained

	writeable = yes

in a service after upgrading to 3.0? In this case, since
all shares are read only by default, there is no
security problem.  However, this is not the case.

If a feature, or parameter is to be removed, it must be
announced to samba at samba.org to solict feedback.  None of this
"developers perogative" stuff.  Then a reasonable plan
must be made for its removal.


> be to add some text to the change logs, in which you
> could write about the removal/addition of any config
> options. Many Samba users compile their own binaries,

Over 50% of the downloads for 2.2.0 from samba.org were binary
packages.  This does not include those which installed
Samba form a vendor's distro of course, so the number
is probably higher.

> and those who do generally read the change logs. Those
> who obtain binaries from the Samba team, and other
> vendors, should be informed during the installation,
> if possible, as it is with RPMs. And, yes, I do

The only management app we have really is SWAT.  Its too easy to
hand wave and go "we'll do this or do that during the upgrade".
Someone has to write those migration tools.  I have not seen
many if all proposals for migrating existing installations.

The exception to this was the "encrypt passwords = yes"
default debate a few months ago.  And I will push to delay
a 3.0 release until this tool is included.

> support a couple production Samba systems; I almost
> always study the differences between each version of
> Samba, using both the change logs, and e-mails from
> the mailing lists. We can't "dumb down" Samba for
> users who aren't willing to learn the _major_
> differences between different versions. After all, you
> don't see any config.sys files on any Windows 2000
> machines, do you? :-) Just my 2 cents . . .

"dumb down" is a bad term here I think.  The problem
is that I've seen proposals for changing things that resulted
in a loss of functionality.  "Samba 2.2 would do this, but
Samba 3.0 won't do XXX".  This is an example of course, but
please consider this possibility.

Now as a side rule, if a feature is broken in 2.2, it should
be fixed or removed.  A parameter can be removed IIF there exists
a migration path for sysadmins to get from here to there.










cheers, jerry
 ---------------------------------------------------------------------
 www.samba.org              SAMBA  Team             jerry_at_samba.org
 www.plainjoe.org                                jerry_at_plainjoe.org
 http://www.hp.com        Hewlett-Packard
 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--