Update on git conversion

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew,

> But you still need a team member to put/pull/push your changes 
> into any of the repositories?

Not for sharing code.  You can push and pull with developers
outside the core team for collaboration or maintain an
alternate tree altogether (e.g. the linux kernel -mm tree
and others listed at http://kernelnewbies.org/FAQ/VariousKernelTrees).

It's similar to the kernel dev cycle.  The Lieutenants are Samba
team members but there is no equivalent to Linus.  The release
manager plays coordinate, not dictator.  The RM merges things to
- -test when there is a general consensus that a feature is good
and ready.  It is generally not the RM's decision.  There may be
extreme exceptions to this, but they should be rare if the process
is done correctly.  The RM can participate in the discussion and
review process as a developer (assuming he or she does in fact
code) carrying equal weight with other participants.

Now back to working with developers who cannot push to the
repository.  Assume that you work with a developer regarding a
new feature.  Your job is to collaborate (if necessary), review
code (required), and ultimately act as the trusted proxy to
commit the code to -unstable.  Once in -unstable, you need other
Team members to sign off on the new code to get it into -test.
What constitutes agreement can be formalized or left informal as
long as the process works.  Once agreement is reached however,
you simply merge the code to your own -test branch and send a
request to pull it into the release -test branch.  At that point,
the pull is only a formality.

The reason that the pull into -test is not automated is so
that people don't short-circuit the discussion and agreement
process (that's what we do now).  But if people don't participate
in the sign-off, the process will break down.  Hence my comments
about people being more important than tools.  It is the tools
that enable the process, but people make the process work.

This work flow should make it easier to rotate release managers
or even have an RM that is not a "developer" since the release
process is simply coordinating pull, updating release notes, and
signing the tarball.  Currently, the RM has to have intimate
knowledge of what is in the release dev tree (e.g. SAMBA_3_2_0)
to evaluate the quality of the upcoming release.  And that is
a real weakness is our current model.

btw...These threads force me to exactly articulate proposed
policy changes which is probably not clear enough from previous
discussions.  So thanks. :-)






cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHB6hSIR7qMdg1EfYRApnGAJ9sDmFs71sTBaC1nCdX6btRFcX2LwCcCAwl
92ixgyvbMaKjxzdDuOeosU8=
=qaDD
-----END PGP SIGNATURE-----