View on project leadership and failures....
Gerald (Jerry) Carter
jerry at samba.org
Thu Aug 31 16:09:36 GMT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Jeremy Allison wrote:
> On Thu, Aug 31, 2006 at 10:26:15AM -0500, Gerald (Jerry) Carter wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Not my own this time.... :-)
>> This is a pretty good email from Charles Hannum (NetBSD).
>> You might have already caught it on /.
>> We could probably point out several things of which we (Samba)
>> as a project have been guilty of. I could probably pin several
>> to myself as a developer as well.
>> I'd suggest reading it and considering whether you think
>> any of it is valid and is something we should openly discuss.
>> I won't seed the discussion with my own thoughts just yet.
>> If not, it's a good read anyways.
> Wow ! What a stunning email. We're certainly guilty of much
> of this. How can we learn from it ?
I dunno. I'm still thinking about it. I think we have
struck on some good ideas lately. The 3.0.x series is
progressing pretty rapidly as opposed to how things
have gone in the past. We do see more patches posted.
Although I think we probably fall down on proper code
review some of the time.
The thing that stood out most to me is how we usually work
on features alone. This probably makes some development
go faster but does inhibit outside involvement.
The "no locking of projects" caught my attention as well.
We all have a tendency to think "If you want something done
right, do it yourself."
And the standards for code quality was another. I'm not
saying that what we check into the tree right now is bad.
But when you contrast this to some other models, the code
we check in is usually incomplete rather than a code-complete
feature. I'm not sure I can fault this since it is
fundamental to how we share ideas and code.
Another example that was just brought up to me this morning
is the lack on consistency in error reporting in the net
command. While I was working on the Using Samba book, I
noticed but sometimes the net tool would give no output
to report success and sometimes print "Success" to stdout.
This kind of stuff is bad interface design and I have a
hunch stems from the lack of coding standards.
And this points back to the incomplete code that goes into
the tree. You can't really review a feature that is not
finished. But once it is in the tree, you have no guarantee
that it will be finished. It's just to easy to forget
about it (from both sides of the development fence).
This is one positive that a Distributed SCM like bzr really has
in my opinion. You have a local SCM for change tracking but
features don't (or at least shouldn't) get merged until they
are complete. But an normal centralized SCM like subversion
will support the same policy that is enforced by a DSCM.
It's more of a work flow issues I think.
In some ways, the SAMBA_3_0 and SAMBA_3_0_23 support this
model. I think this is one good thing we have done lately.
Samba ------- http://www.samba.org
Centeris ----------- http://www.centeris.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the samba-technical