Update on git conversion

[Andrew Bartlett]

On Sat, 2007-10-06 at 04:42 -0500, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andrew,
> 
> > What happened to this being an experiment, for us all to 
> > assess at the end of a couple of months?  I'm a bit lost at
> > what changed from when we discussed this, sorry.
> 
> Yes. We agreed to a four week or so probationary period.  That
> has not changed.  But I would not have proposed the migration
> had I expected it to fail.  And I am not approaching it as such.
> Git would literally have to loose our data IMO for this to fail.

Hmm, perhaps we should have defined the success conditions for this?
Not that I expect the git migration to fail them, but surely the
definition of success is more like:

 - build farm successfully tests the resulting trees, without excessive
bandwidth or space costs on member servers
 - build farm still displays recent checkins
 - websvn replacement works well
 - workflow isn't disrupted unduly by tool issues
 - all relevant developers have the tools behave, and there are no major
inter-version issues
 - samba-cvs gets mails on commit
and then finally
 - no data loss (including history to this point)

> But it seems that you are less enthusiastic and optimistic than I.
> 
> The model we are moving to is very similar to what we have now
> in the 3.x branches.
> 
> * v3-2-unstable is SAMBA_3_2
> * v3-2-test is SAMBA_3_2_0
> * v3-2-stable is SAMBA_3_2_RELEASE
> 
> The change in workflow means that individual developers no longer
> have to do dual checkins to SAMBA_3_2 and SAMBA_3_2_0, only to
> the *-unstable branch.  git-merge (or git-cherry-pick) are far
> superior to "svn merge" in my experience.  So we can have a policy
> that keeps *-test in a more stable state without the half finished
> work.  And therefore *-stable is truly "stable".  And by having a
> rolling *-stable tree which can move towards time based releases
> easier.
> 
> But the real advantage is that others can now freely participate
> in the full development cycle because the distinction between core
> and non-core is gone.  What matters is code quality alone.

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

> >> There are non-technical reasons to move to git that you should
> >> consider as well.  But you guys decide what you want to do.
> > 
> > I keep getting this hand-waving, and keep missing what
> > you mean.  Care to give me a clue?
> 
> It's no hand waving.  Trust me on this one.  But I'm not going
> to risk the git migration by becoming involved in what could be
> viewed as political issues.

I still have *no* idea what you refer to as these 'political issues'!
Could you enumerate some, so I can know what you mean? 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20071006/8776a53c/attachment.bin