Update on git conversion
abartlet at samba.org
Sat Oct 6 10:41:41 GMT 2007
On Sat, 2007-10-06 at 04:42 -0500, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> > 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
- 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
> 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?
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
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20071006/8776a53c/attachment.bin
More information about the samba-technical