Is there a reason to have source4 in 3.4 releases?

[John H Terpstra - Samba Team]

Derrell Lipman wrote:
> On Wed, Jul 15, 2009 at 7:47 AM, Michael Adam <obnox at samba.org> wrote:
> 
>> Andrew Bartlett wrote:
>>
>>
>>> You could label the folder 'danger-dragons-never-ever-touch'
>>> and still have people ask about it.
>>  No, we have to tell them clearly that there is no samba4 release
>> within the s3 tarball to be supported. For the decision about the
>> removal of the source4 tree from 3.4.1, others should raise their
>> voices. I personally have not problem with it sticking there, but
>> when people agree that it is irritating and misleading, then it
>> should probably go.
>>
> 
> Although I can laugh at Andrew's comment about danger dragons, I don't think
> the situation is quite that dire. Currently there is nothing in the naming
> to indicate how "ready" or "released" samba4 is in relation to samba3
> (except, of course, that it's part of the samba3 release tarball). I like
> the current trend towards Frankie included in the releases. I'd suggest
> simply renaming the samba4 directory, in master and 3.4 branches, to
> samba4-prerelease or samba4-work-in-progress or even
> samba4-prerelease-work-in-progress (the latter is probably overzealous) just
> so it's clear that the samba4 code is not yet production ready. We will
> likely still get occasional questions about it, but at least they're well
> fore-warned. When samba4/Frankie is ready for a real release, the directory
> can be renamed back to samba4.
> 
> Derrell

Gentle folk,

We are falling into the trap of doing what we do best!  We are thinking
like programmers who seek to solve a management problem with a technical
solution!

Does it matter in the least what the samba4 directory is called?

I urge you all to consider the real issue.  Our problem is fundamentally
one of lack of clarity in respect of our roadmap.

Network managers and administrators want to know:
	1) What is ready for use?
	2) How do I use it?
	3) What benefits do I get?

Can we not provide a roadmap? One that spells out:
	a) Which parts of the currently stable parts of Samba live in
           each directory
	b) What the "current" development schedule is for each WIP
            (WIP == Work in progress) and projected "ready date"
        c) A list of future projects and a current ranking of importance

We should stress that the a new feature may, or may not, be ready within
the indicated time-frame.  Tell our users to check the Roadmap to see
how our estimates change at each release.

If a component is not ready, per the clear current status of samba4 in
Franky, then spell out loudly in the Roadmap - *IT AINT READY!!!*  We
will tell you when it is ready:
	  I) For testing and feedback
	 II) For debugging and QA
	III) For release to production use

I fail to understand why we need to mess with renaming of directories
when a roadmap is a far more elegant solution _AND_ saves confusion in
the long run.

Folks, we are at a point where the team needs to re-group around a
single united project.  Does anyone else see that?  We can have project
groups within the project, but then our users want/need to know how each
project group relates to the whole. We do not have that today.  Addition
of samba4 has now compounded the confusion.

Somehow, some way, we need to re-present Samba to the user world in a
more cohesive and tangible way.  We are losing ground.  We are losing
users.  We are losing support.

Too many corporate sites have moved away from Samba because they could
not see a roadmap, failed to understand our direction, could no longer
wait for AD server support, and had too many problems.  Each time a
problem was has been raised I have been able to point them to the fix,
but they had already abandoned Samba.  The problem is not technical - it
is a communication challenge.

In the heat of our team discussions we seem to revert to a sense of
being overwhelmed with things that need to be done and a lack of
resources to do them.  The fact that this is the case is good!  All the
more reason why we need to tell our users what we are doing and all the
exciting things we can see ahead.  Our critical problems are not
technical - they originate around communication, collaboration, and
self-management.

We need clarity and unity in direction.  Can we seize hold of the
opportunity before us? I believe we can, if we all work at this together.

If we agree that something needs to be done, and we are all willing to
work towards a consensus, then we are well on our way to a solution to
our current dilemma. I understand that the changes we need to make will
be painful to some, but I am equally sure that none of us want to see
Samba die on the vine.

So sorry this ended up as long as it is.

- John T.