group_mapping.ldb and 3.0.25

Gerald (Jerry) Carter jerry at
Wed Feb 21 03:17:24 GMT 2007

Hash: SHA1


I understand where you are coming from, but I do believe
that it is a unfair for you to pop up every now and then
only when you disagree with how something is handled in
the production releases.  And I also know that you will
believe that statement to be untrue.  That's ok.  It is
just how things appear to me.

> Your mail makes pretty clear that Volker, Jeremy and 
> you have formed a 'sub-team'. This has happened over
> the last couple of years, with the boundaries
> of that sub-team becoming more and more
> defined. Discussions within that sub-team and 
> often not public, but the decisions made by that sub-
> team seem to be binding, and not open to discussion.

"Not open to discussion" is incorrect.  If you like
I can post URLs to emails on samba-technical where
I have reconsidered or been persuaded to change my
original opinion.

Everything I do here, I do for the sake of the Samba
project.  If you don't want to do my job, then please
provide direct examples where I have gone against
the majority of people and done my own thing.  And
please provide direct examples of where there is
general dissatisfaction in how I am handling releases.

Or if you prefer we can simply elect a release manager
for Samba 3.0.x instead of having a volunteer.  And we
can rotate that on an annual basis.    If you don't
like how I'm handling this, just get enough people
vote me off the island.  Sound fair?  Or if you would
like to have my job, I'll be glad to hand it over.  We
have a 3.0.25pre1 release due out tomorrow.   Now would
be a good time. :-)

> If we are going to have a 'sub-team' like this 
> then I want that decision to be made by all of the
> Samba Team, not just have it happen.

I find it hard to believe that the current working
relationships surprise anyone.  Everyone, including
yourself, already know how things work.  I have discussed
the emergence of the current culture with you and
on the team before.  I'm not discussing this again.
Please re-read the team lists if you want to re-live

> We setup a particular team structure when the 
> Samba Team was started which is very
> different from what is practiced now. If we are
> going to change that structure then I would like 
> to see discussion of that new structure at the
> very least on the samba team list.

You and I have very different release methodologies.  You
have said before that you would just throw tarballs over
the fence every week.  I don't work like that.  You have
always pushed back against any kind of structure.  That's
fine.  So don't impose your view of structure on me.

> I know that being the release manager is a thankless 
> and very time consuming task, and I appreciate how
> much effort you put into it. I am just hoping
> for future releases that there be a bit more transparency
> in the processes that lead up to the decisions for 
> each release.

I understand all of your points and your concerns are duly
noted.  But please understand that I'm not seeking your
approval of what I do.  I will follow what I believe to be
the wishes of the majority of developers and users working
on Samba.  If people in the community are dissatisfied
with my work, please have them email me directly and I
will work diligently to resolve any open issues.  But at
some point, has to make tough and potentially controversial
decisions.  That's the nature of managing releases.

The #samba-technical IRC channel is transparent enough
for SAMBA_4_0 development so I'll shoot for that model
as my initial target.

cheers, jerry

Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla -


More information about the samba-technical mailing list