Deleting parameters.

[Gerald (Jerry) Carter]

On Sat, 10 Nov 2001, Andrew Tridgell wrote:

> > Of course I'm sure tridge will disagree with this.... :-) :-).
>
> yes, I disagree. There are some parameters that are just too evil to
> live. A good example is the old krb4 and krb5 configure
> parameters. They should be removed because:
>
> 1) they required compile time changes, which very few people do

OK.  I'll play devil's advocate here.  Have you asked ?  Or are we
assuming?  Now I will also point out that as I did to Andrew B.
that removing the --with-krb5 option removes certain functionality
that I do not think can be supported in 3.0.  Namely, logons
using Kerberos from non-win2000 clients with a non-PAM server
(which there are many).

> 2) they only work with plaintext passwords on the wire, which means
>    they need client hacks

So? What is the point here?  People who logon against NIS or /etc/passwd
for convience do the same thing.

> 3) they are completely superceded by our new kerberos code

Not entirely. See above.

> Same goes for the SSL support code. It is a nasty, gross hack that
> makes our code harder to maintain.

Again, I think that VPN's are a much better option for this, but I think
Jeremy's initial comments was about parameters, not configure options.

> What you forget about in your view on keeping parameters is that there
> is a tradeoff between keeping old parameters and keeping the code
> maintained. Leaving in code that nobody actively maintains and that
> makes the code less maintainable increases the number of bugs for
> *everyone*, whereas keeping the parameter helps maybe one person who
> happens to use that parameter. We do not have the resources to

The problem is that it can be very hard to determine who is actually
using a parameter.

There are two basic issues here:

  * migration of 2.2 type parameters to 3.0 (there must be a migration
    plan other than vi/emacs)
  * changes in functionality (things you used to be able to do
    and can't anymore)

> Andrew and I will be removing some of these unmaintained options from
> the head branch. If you want to put them back in, then fine, but
> please don't do so unless you can guarantee they will be maintained. I
> know you don't have the time to do it yourself, so you'll have to find
> someone willing to do it. If you can't then don't add it back in.

Please announce on samba at samba.org when you choose to remove anything
to test the waters and explain the impact of the change.  We've gotten
burned in the past by the perception that we develop in a vaccum. :-)









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--