group_mapping.ldb and 3.0.25

[tridge at samba.org]

Jerry,

To make it clear what this discussion is about, I won't try and
reverse the decision to include ldb in this release. That is minor,
but symptomatic of what I see as a larger problem, one that has been
going on for a long time.

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.

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. 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.

 > I agree you are quick to fix a bug if it's pointed out to you.
 > But you cannot honestly tell me that you pro-actively work
 > releasing the 3.0.x tree. Do you even personally run SAMBA_3_0
 > on a daily basis or use the group mapping code?

To cope with running as much code as possible on a daily basis I built
the build farm and built up a test system. Nobody on the team tests
all the code they maintain on a daily basis. I do run Samba3 all the
time on multiple machines, and I support it on customer machines. I
can't say how often each line of code in the group mapping code gets
run on a daily basis, as I don't run production systems with code
coverage enabled.

If you would like to propose that code only be accepted into a release
if the author personally runs that code on a daily basis and promises
to continue running it on a daily basis then please propose that to
the team. However if we adopted that standard then I think you'd find
that a very large part of Samba3 would need to be removed from
release.

 > Case in point: Jeremy & Guenter tell me of this great
 > offline logon feature they had working on SLED 10.
 > Then I start trying to use it.  Doesn't work for me.
 > Why?  Because it had been tested in a certain type of
 > configuration.  But now I have it working after a few
 > fixes and can feel confident in it.

excellent example, with a good techical reason for not releasing the
code. The code didn't work for someone who was testing it.

 > Another case: Simo designed a new idmap interface based on
 > discussions on samba-technical.  Works for him.  Doesn't
 > work for me.  And in fact I find certain cases that were
 > never tested. No offense to Simo.  This is the nature of
 > the game.  In fact, Simo's code actually was part of the bugs
 > with the offline logon support.  Now I have backwards compatible
 > configurations and new idmap domain configurations working.

Another great example. The code didn't work for someone who tested it.

I don't have a problem with either of these examples. When code
doesn't work it should not be released.

That wasn't what happened with ldb. With ldb there are no bugs
reported, nobody has said it doesn't work. The bug you found when I
first wrote it was fixed 4 months ago, within hours of you finding it.

What seems to be happening is that decisions are being made based on
'who' rather than 'what'. I don't think that is healthy.

 > Jeremy, Volker, and I don't want to ship ldb in 3.0.25 just
 > for group mapping.  We never have.

I won't try to change that now, but I would like you to understand why
that statement disturbs me. To the best of my knowledge there has
never been any discussion on either the team list or on the open lists
that suggests the above statement. Perhaps you don't realise just how
much the discussion on this has been private?

Not including ldb in 3.0.25 could be the right decision. If Simo
doesn't want ldb released yet then it probably is the right
decision. But how am I supposed to know if its the right decision if
I can't participate in the discussion?

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.

Cheers, Tridge