svn commit: samba r23120 - in branches/SAMBA_3_0_25/source: include libsmb

Gerald (Jerry) Carter jerry at
Thu May 24 19:04:13 GMT 2007

Hash: SHA1

Hey Derrell,

>> I've already cut the tarball and Fedora RPMs.  We'll 
>> catch this for 3.0.25b.
> This is *really* frustrating.  Having *THREE* trees to 
> have to check in to, with some of them temporarily
> "locked" makes code management completely unreasonable.
> This change was made weeks ago.

But *you* did not merge it into SAMBA_3_0_25.  This has
been a long standing policy and IIRC not the first time that
you failed to merge your own fixes.  I've mailed the list
several times when the release branch was sync'd with
SAMBA_3_0_25.  You have to realize that if you don't check
you code it, it would not be in the 25a release.

btw...the only tree that is actually locked is
SAMBA_3_0_RELEASE.  The SAMBA_3_0_25 may be temporarily
frozen but what that means is that I'm not pulling in
any more changes from that branch currently.

> I was awaiting release of 3.0.25a with these changes, 
> and this is going to completely screw me up.  (You
> said you'd be cutting tomorrow and asked for testing
> today, which is what I did, and which is how I found
> this.)

ok.  Fine.  I'll take it.  In the future, please merge your
own changes.   The strategy is straightforward:

SAMBA_3_0_25 		-> Samba 3.0.25 series
SAMBA_3_0_26		-> Samba 3.0.26 series
SAMBA_3_0		-> research or works-in-progress

I'm not planning any bulk merges between SAMBA_3_0 and
SAMBA_3_0_26.  I might do some house cleaning but don't
depend on it for inclusion in the release.

cheers, jerry
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the samba-technical mailing list