s4member environment and 'useless' tests

[Rowland Penny]

On Wed, 11 Jan 2017 10:24:46 +1300
Andrew Bartlett <abartlet at samba.org> wrote:

> On Tue, 2017-01-10 at 12:18 +0000, Rowland Penny wrote:
> > On Tue, 10 Jan 2017 12:22:15 +0100
> > Andreas Schneider <asn at samba.org> wrote:
> > 
> > > 
> > > I'm also waiting for a explanation what a s4member actually is ...
> > > 
> > > 
> > 
> > It seems to be a provisioned member server, something the Samba wiki
> > forcefully tells you not to do, see here:
> > https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member#
> > Joining_the_Domain
> > 
> > So, I will ask again, why are we testing against something we tell
> > users not to use and is actually broken ???
> 
> Because it isn't so broken as to not be worth keeping the code
> working.

It doesn't work, you said so yourself.

> 
> There is a big difference between the set of configurations that we
> strongly recommend our users use, and those we may have code for.  We
> still have most of the code for the OpenLDAP backend for example, with
> even more dire warnings.  You and I have had long and unresolved
> discussions about the ntvfs file server in a similar way. 

If I recall correctly, there is some group (or is it some one) trying
to get ldap to work, so keeping this code is understandable. What isn't
understandable is keeping old code around that isn't ever likely to be
used in production and then running tests against it. What will this
show ? that the main code that is used, works with code that will never
be used ?

> 
> In this specific case, until recently this code path was important for
> the openchange project.  (Openchange sadly is no longer under
> development, particularly for the server).

Yes. Openchange seems to have died, so you are proposing to keep test
code around for a dead project, just in case it re-animates itself ?
Also, just in case you haven't noticed, I am only proposing removing
test code, I haven't proposed removing any 'C' code, just python & perl.
 
> 
> It also tests, alongside rpc_proxy, the python domain-join code (an
> alternative to the C based code in 'net').

Then the test needs to be pointed at an AD DC joined to a test domain,
this is what we need to be sure works.
  
> 
> I would be much more convinced if the tests of this environment were
> blocking code development, or they take a long time, but removing them
> *because they found an actual bug* seems a bit strange.

The problem, as far as a understood it, was that a test against
's4member' was failing, I asked why we were doing this and Michael
Adam said 'Agreed. Let's remove it...' , so I created the patches.

> I am happy if s4member and rpc_proxy are combined, but given the
> changes I did in da3a79831afbd1b85592be36eb47de375e575643 to make it
> work, I'm not sure if the two are compatible.
> 
> Andrew Bartlett
> 

Can I be blunt, just what do you have against removing old, no longer
really useful code ? Tests should be relevant, even if it means writing
new tests. 
 
Rowland