don_mccall at hp.com
Sat Nov 10 16:18:01 GMT 2001
My 2 cents worth -as someone who makes his living
supporting customers that use samba (and other
nos'es)... Backwards compatibility between versions
is an admirable thing, and we want to respect it as
much as possible. On the other hand, you must have some
way to clean the code base of irrelevant/depreciated code,
and major releases are probably the best vehicle for this.
What I have seen done in the past with other products is
some sort of automigration script, that is run to detect
depreciated code/options, and replace appropriate config
options or structures with newer methods. Perhaps something
of this sort could be implemented, and the migration script
be referenced in a DEBUG 0 log entry, or even a stderr message
when running smbd when it recognizes a depreciated parameter in
the smb.conf file...
From: Sean Elble [mailto:s_elble at yahoo.com]
Sent: Saturday, November 10, 2001 7:03 PM
To: Jeremy Allison; Andrew Bartlett
Cc: samba-technical at lists.samba.org
Subject: Re: Deleting parameters.
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
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,
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
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 . . .
--- Jeremy Allison <jra at samba.org> wrote:
> Tridge and I disagree (sometimes violently :-) on
> the removal/changing
> of parameters. My position is that once a parameter
> is out there in
> a production release, we can't just yank it out,
> even in a future major
> revision, as many sites just upgrade Samba and
> expect their existing
> smb.conf to keep on working.
> Andrew feels we can do anything we want (within
> reason of course :-)
> on a major upgrade. The problem is that "within
> reason" is defined
> in the eye of the beholder :-).
> IMHO This is not a reasonable assumption :-). I'm
> sure Dave Collier-Brown, Jerry,
> Herb, the HP-CIFS/9000 Team and anyone who has to
> support production Samba
> systems would agree with me.
> In order to retire parameters we need to migrate
> their intent to new
> parameters on upgrade, and only after two or so
> major upgrades can
> we delete them entirely.
> This should be a lesson to scare us away from adding
> too many new
> parameters :-) :-) :-).
> Of course I'm sure tridge will disagree with
> this.... :-) :-).
Sean P. Elble
Editor, Writer, Co-Webmaster
ReactiveLinux.com (Formerly MaximumLinux.org)
elbles at reactivelinux.com
Do You Yahoo!?
Find a job, post your resume.
More information about the samba-technical