Deleting parameters.

Sean Elble s_elble at yahoo.com
Sat Nov 10 17:01:05 GMT 2001


I like that idea . . . it shouldn't be too hard to
implement (for you programmers anyway :-), and it
would offer the "best of both worlds". Perhaps the
automigration script, as you call it, could provide
the user with some information about the depreciated
option, like why it was depreciated, what, if any
option has replaced it, and any important changes that
must be made to values of any option. Now that I think
about it some more, I _really_ like that idea. :-)
--- "MCCALL,DON (HP-USA,ex1)" <don_mccall at hp.com>
wrote:
> Well,
> 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...
> Don
> 
> -----Original Message-----
> 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:
> > Andrew,
> > 
> > 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.... :-) :-).
> > 
> > Jeremy.
> > 
> 
> 
> =====
> -----------------------------------------------
> Sean P. Elble
> Editor, Writer, Co-Webmaster
> ReactiveLinux.com (Formerly MaximumLinux.org)
> http://www.reactivelinux.com/
> elbles at reactivelinux.com
> -----------------------------------------------
> 
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
> 


=====
-----------------------------------------------
Sean P. Elble
Editor, Writer, Co-Webmaster
ReactiveLinux.com (Formerly MaximumLinux.org)
http://www.reactivelinux.com/
elbles at reactivelinux.com
-----------------------------------------------

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com




More information about the samba-technical mailing list