SYSKEY2. Request For Comments

[George Cameron]

> Let me just stick in my 2 cents please. I have no idea whether SYSKEY is a 
good
> thing in samba or not but in general I find the work that Luke is doing to be
> pretty good stuff. The DC code, the rpcclient code, the DSO break -up, it's 
all
> excellent. Note that I'm NOT saying what all the other guys are doing is not
> great but from my point-of-view at the moment, the TNG branch has the most
> activity and the most new features. If he wants to go off on a tangent and 
play
> with SYSKEY then "why not".

No, I don't agree with that. Samba is fully professional software in most
people's estimation. It takes a lot of work to attain and retain that quality.
Samba is also cutting edge, ground-breaking software - the evolving
PDC capabilities are very impressive and much-needed. Its fast
evolution and new capabilities are very desirable in such a fast-changing
and competitive arena as computing.

But these two aspects (quality, capability), while both essential, can
sometimes compete. AND Samba is a shared, distributed project, which is
in itself a task and a half to administer.

So the "why not" is that it is essential to prevent Samba from fragmenting.
A code branch can be a good idea, but it needs a backwards glance on a
regular basis to consider how easy it is going to be to re-integrate new
developments into the main code - just as important as getting the next
piece of protocol working.

So I have sympathies with both sides - Luke's work is to be highly
commended and keeps Samba at the forefront, but Jeremy and Andrew's
striving for quality and maintainability mean that their angle is
also valid. So my (humble) suggestion would be that it might be
worth detuning the 'performance engine' by a couple of percentage
points (98% of your current speed is still pretty damn good) and if
you really do re-deploy that effort into dialogue with the main branch
folks on exactly how and when to incorporate the new developments into
the mainstream, that should help to keep  them happier AND is probably
the fastest way of getting the 'new generation' out into the field,
which should keep both the hungry users (and yourself) happy!

For a case like this, I think you need something like the RFC, but when
it (unexpectedly I guess) turned up so much controversy, I would
re-submit it couched in different terms:

   1.	what I believe the problem to be
   2.	where it manifests itself
   3.	what I think Samba's role should be in addressing it
   4.	list of possible options for solution
   5.	my preferred option and why

Then discuss for a bit (amongst the Samba team probably rather than
the wider discussion list) to try to obtain consensus - even having a
counted vote if you find that people are not in agreement. And then
*stick by the consensus*. Only in the most exceptional circumstances
should somebody branch out against the group, and then only on the
basis of making it a temporary fully private development, and being 
able to demonstrate something and win the others around once you can
demonstrate that it really does have its merits. In this case I guess
it's a policy issue rather than a performance one, so it should
really be decided in advance.

OK, I'm only an interested observer, and perhaps sticking my neck
out a bit, but this was my reaction to the recent discussion - my
my .02's worth also I suppose.

 ---------------------------------------------------------------------
 George Cameron		   g.cameron at biomed.abdn.ac.uk
 Dept. BioMedical Physics
 Aberdeen University
 Foresterhill		   Fax:	      +44 (0)1224-685645
 Aberdeen AB25 2ZD	   Telephone: +44 (0)1224-553210
 Scotland, UK