jkt at gentoo
Oct 17, 2010, 9:52 PM
Post #7 of 7
Joshua Saddler wrote:
> - Bugzilla changes for drafts and patches? How much would still be
> posted there when we could just have people send pull requests to
> their git clones of our master?
I have no preference, but would recommend to follow the rest of Gentoo
> - What about branching? Needed for what we do? What about the
> handbooks? (We used to always do something like that for the
> networkless handbooks, which is partly why we no longer keep
> versioned handbooks around.)
I can't see how using Git branches would reduce the work here, though --
you still have to write the patches (English text is much less
structured than C code, so you likely won't be able to make use of
> - Internal doc formatting: should we abandon the <version> scheme,
> since we can just use git commit hashes? It would reduce the manual
> bumping we do (and forget to do). How would that work with git
No, we can't abandon that for the same reason why we do not use CVS
keywords or anything. Content change is to be determined by the
author/committer, not by the simple fact that "someone changed that file".
> - Speaking of history: we'd need a way to carry over CVS history to
> Git history; we absolutely CANNOT lose the merge/update history, or
> all the docs that are in and out of the CVS "attic." Often enough
> we get bugs asking for additions or changes, but it's been settled
> and explained in previous commits and CVS logs.
That's the usual case when migrating between VCSes, history is always kept.
> - Cloning and initial checkouts could be quite nice for translators
> and English devs alike; merging branches and managing contributors
> would be much more flexible and fine-grained. We could host all
> clones on gentoo's git, or even if we continue to have multiple
> separate repos, git makes it easy to pull and merge those changes
> regardless of location.
In fact, any modern VCS is better than CVS. You'd no longer have to do
SSH tricks in order to get a decent performance from CVS (it likes to
establish a fresh connection for each file, IIRC).
> Git access will ultimately require "gitolite" to be ready. Gitolite
> is a perl-based replacement for gitosis-gentoo, which serves up all
> our git trees ATM.
Is that infra's requirement? From a POV of a GDP member and a
translator, I couldn't care less about what is used on the web for git
> I wouldn't mind moving to git, but I already have some limited
> experience using it for a year or so. Not all of our contributors are
> familiar with it, and even I need to learn more about how git works,
> since it's so different from CVS. I imagine we might have some
> holdouts who don't want to move from CVS at all, so now's the time to
> speak up. What does the rest of the GDP think about moving to git?
In my opinion, we should go for it.
cd /local/pub && more beer > /dev/mouth