jkt at gentoo
Oct 17, 2010, 9:52 PM
Post #7 of 7
(967 views)
Permalink
|
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
projects.
> - 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
> history?
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
browsing.
> 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.
Cheers,
-jkt
--
cd /local/pub && more beer > /dev/mouth
|
signature.asc
