Guidelines for releasing Samba PDC support
pgmtekn at algonet.se
Sat Nov 6 09:09:27 GMT 1999
> > The problem is that the 2.1 code was never complete w.r.t.
> > some things like user/group/alias management. This is a
> > basic requirement of an 'official' PDC.
> > Now I know Luke has 1000 different irons in the fire, with
> > NTLMSSPv2, the new rpcclient code etc. etc., but this
> > means that the HEAD branch is in a state of *constant* flux,
> > which no-one except Luke can deal with (as he's the one
> > causing it :-).
> > I'm hoping that J.F.'s snapshot freeze will provide a stable
> > enough base to attack this problem with a non-mutating
> > code base.
> here is the problem :-) I want a stable merge release and at the
> all of Luke's new code. I don't want to see yet another samba branch
> the cvs repository. Merging 2 versions and storing it in a new
branch is a
> complete non-sense.
This would depend on how similar your merged code is to compared to
the HEAD code, and our goals in regards to the immediate priorities.
If your code is structured differently from the current head or we
want the code to become public soon, then it would make sense to
freeze (kill) the current head and start a 2.1.2 new head branch. This
would allow you to finish the merge with from stable code bases and
force anyone who is writing code to adjust it to your new code (and
avoid the double work of fitting it into both the current head and
At the same time, two related issues could be brought up. Couldn't
some programmer-guru (or at least the samba team) check submitted (and
possibly the self-produced) patches before applying them (I think this
is done in 2.0.X but I'm unsure in 2.1.X).
How should we avoid the (at least from a philosophical point of view)
stunning fact that users are directing each other to use head branch
in production environments. Are we failing to in a timely maner move
the most needed code parts (PDC) from head to stable (are we correct
in doing so because we just don't know enough about it yet), or are we
allowing virtually untransferable code to go into head?
> > The HEAD code in J.F.'s port will need to use the tested
> > 2.0.x RPC code, with error checks etc. He may already
> > have done this.
> That's what I'm doing right now.
> > Good idea bringing this discussion up though.
> there are still *many* technical issues to resolve before using the
> as a base for the next samba version.
This *could* be what samba should concentrate on (I'm not looking at
pgmtekn-micke at algonet.se
More information about the samba-technical