Name Change for Samba4? [Re: What is blocking a Samba4 Tech Preview?]

[Kurt Pfeifle]

On Monday 19 December 2005 12:06, Steve Langasek wrote on samba-technical:

> Message: 15
> Date: Mon, 19 Dec 2005 02:55:58 -0800
> From: Steve Langasek <vorlon at debian.org>
> Subject: Re: What is blocking a Samba4 Tech Preview?
> To: samba-technical at lists.samba.org
> Message-ID: <20051219105558.GA4797 at tennyson.dodds.net>
> 
> On Sun, Dec 18, 2005 at 10:06:55PM +0100, Jelmer Vernooij wrote:
> > > If we can get some of this code out into the hands of users, we might
> > > get the interest and developers we so desperately need, but doing
> > > 'nothing' (ie continuing development) isn't going to move us.
> > Certainly! The Debian packages of Samba4 are a bit more sane now,
> > after a couple of patches from Steinar Gunderson (Sesse for those on
> > IRC), so I hope we can get some Samba4 packages in Debians
> > experimental as well.
> 
> What is the (eventual) upgrade path from samba3 to samba4 going to look
> like?  I would like to see samba4 packages in experimental at some point,
> but I'm not really happy with the idea of renamed packages; 

Why? Does your unhappiness have a real cause?

Speaking for myself (a lowly user only, not capable of reading more 
than comments in the code, not capable of building packages for any 
distro, and thusly not really knowing how much work is involved for 
those who have to actually implement the following suggestions):

 -------------------------------------------------------------------
  * Please rename the Samba version 4.x into Samba4 1.0 (or into an
    otherwise different one from "Samba") 
  * Don't just give a new name to the package facing the "outside 
    world", do also rename all the binaries, important files and 
    directories [smbd4, nmbd4, smb4.conf, winbindd4, /etc/samba4/, 
    /var/lib/samba4/ (or wherever the various distros put stuff), 
    passdb4.tdb, secrets4.tdb, ...e etc.pp.]
 --------------------------------------------------------------------

Here are my reasons:

* it signals very clearly to any user (== box admin who installs it) 
  that Samba4 is a completely new design, that there are many things 
  in Samba4's config and behaviour which are changed from Samba 3.x,
  and that this is a major upgrade or system change...

* ...but at the same time this system change would allow to install 
  and run Samba4 side by side with Samba 3.x on one and the same box 
  (albeit not at the same time, unless they'd use different ports);

* this would not only make interesting test scenarios, and quickly 
  lead to many, many, many, many more testers (you'll probably get 
  within 2 months 200 who are outside of the Samba Team instead of 
  the 20 which I guess are currently compiling and testing samba4 
  SVN code);

* it would allow to give the migration/settings/users/domain export
  and transition from Samba to Samba4 a really thorough testing well
  in advance of any first official release, and starting right with
  your first Tech Review release;

* the dreaded "One-Way" migration path miraculously turns into one 
  that has a good safety net underpinning, because a dual approach 
  would give an easy way to back down from a failed upgrade, so a 
  productive server can resume to run version 3.x again within a 
  few minutes and a fix or better configuration can be prepared or
  waited for until a new 4.0 rollout attempt. More people would 
  *dare* to upgrade earlier due to this easy roll-back assurance,
  and ironically, less people would actually need to roll back as
  well.


But as you might have guessed already, I have not the faintest idea 
how much work is involved in making these changes, and how long it 
would take you. Hopefully the other benefits of this are obvious to 
all of you, so you can weigh them against the effort involved:

 * more general exposure of Samba4 before release; more clueless 
   journalists writing reviews and sneak previews; more beta testers; 
   more bug reports; (possibly) more patches; (possibly) some new
   developers; more fame, more fun... And more praises from me
   thrown towards the Samba Team for implementing my humble wish. ;-)

 * it would be easy to include Samba4 onto Knoppix-type Live CDs/DVDs
   (they could ship both, being sure they'll not loose Samba3
   functionality, while having "experimental" Samba4 included).

 * even *I* would be starting to install and use Samba4 on my test 
   and play systems. And I would start writing bits and pieces of 
   documentation. Yes, I promise. (Otherwise, not. Or very late 
   in the game only. Yes, I scare you now  ;-P  ).

Don't say "this is not important for a Tech Preview". It may make the
difference of 20 people outside the Samba Team actually giving it a 
serious spin, or 50, or even 200, on 20 machines, or on 100 or even 600
machines. If you see value in such an increase of the number at all... 
(As you can see, I am not being unrealistic and assuming 1000s of beta 
testers because of this proposal. But I do seriously see the abstention 
of at least half a dozen experienced Samba3 admins from beta testing 
because of the current limitations...).  [*]

> it seems to me 
> this will just make it more difficult for us to support upgrades from 
> these packages once samba4 is released.

As you can see from my arguments above, I do not quite concur with 
this argument here  ;-)

> Cheers,
> Steve Langasek 

Cheers,
Kurt

[*] Currently, I personally do not *run* samba4 code anywhere (Yes, I 
    checked out the SVN and update/compile from time to time. I have 
    power over various Linux test systems at my workplace (SUSE-9.x,
    SUSE 10.0, Debian, Knoppix and (K)Ubuntu). Currently, I am 
    thinking hard which one to "sacrifice" for starting to testdrive 
    Samba 4.0. However, for one, there are no ready-made packages 
    available. With an option to install both side by side and without 
    conflicting names on one machine, this question would turn to be a 
    no-brainer. And I bet, more people would be induced to build
    packages for their distros. Others like me would use them. And 
    isn't it a major effort even for each Samba Team member themselves 
    to accomodate "old" and "new" code and self-compiled binaries on 
    their development machines by employing "--prefix" tricks and 
    other band aid??