Proposal: rename v3-3-test to v3-devel (discussion on#samba-technical)

Gerald (Jerry) Carter jerry at samba.org
Fri Apr 25 16:21:30 GMT 2008


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

(I see that Michael has beat me to the summary but since
I've already spent some time on diagrams here, I'll still
sending the mail out).

This is an informative mail only for explanation and
discussion.  No changes affected by this mail. :-)

There was a lot of discussion about the v3-3-test branch
on #samba-technical so I'll try to summarize it here:

Basically what we have in git history is

- ---- v3-0-test ----+---+-----
     \
      \---- v3-2-test ----+---+-----
            \
             \---- v3-3-test ----+---+-----

- --- v4-0-test ----+---+-----

Since the Samba 4 branch basically has a completely separate
code history, I'll ignore it for the branch discussion that
follows.

My experience has been that developers like to continue coding
while release managers like to stop it :-)  So the only real
way to keep both sides sane is to move the developers to another
branch so that the rate of change in the release tree drops.

Kai made the point that we are indirectly simply using
a trunk & release model:


- ----- v3-devel (a.k.a. trunk) ----+----+----+----+----
   \                   \              \
    \----v3-0 ----      \---- v3-2-    \---- v3-3

which is much more intuitive and actually requires less
branching for developers, but more for the RM (release manager).
All of these are variations on the same work flow we have
always done when it comes right down to it.

In an effort to reduce the confusion, the suggestion was
made that v3-3-test should really be called v3-devel.  When
the November/December release is ready, Karolin would simply
branches from v3-devel to create a v3-3 branch for release.
All coders simply work on the v3-devel branch and never
have to worry about branching again.  To which Guenther
replied:

   gd: +1 on v3-devel

The side effect of this model (release every 6 months and
increment the minor revision number) is that all micro
releases (3.X.y where y is the micro release) are strictly
bug fix releases and no more letter releases.  To this
one point, Simo posted:

   idra: I love anyone that agrees on dropping letters :-)

And clearly using the trunk & release model, we could
potentially drop the -stable branch al together since
anything checked into the v3-X release branch is required
to already be "stable".

The executive summary of this is that

  A. Developers no longer have to worry about changing
     branches after release
  B. The release manager no long has to cherry-pick fixes
     but still has a high degree of confidence in the release
  C. No one is blocked waiting for a "pull" to the release
     branch.

Hope this makes more sense to people now.  No more branching
changes right now.  Just work on v3-3-test.






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

iD8DBQFIEgUKIR7qMdg1EfYRArIGAKCEYSdRvme/K5us2wRJz785LGAs1gCgwX79
FeJ/roBXro6s2vhg7QVmNHM=
=QpQS
-----END PGP SIGNATURE-----


More information about the samba-technical mailing list