Gentoo Archives: gentoo-doc

From: "Jan Kundrát" <jkt@g.o>
To: gentoo-doc@l.g.o
Subject: Re: [gentoo-doc] Documentation/website in git?
Date: Mon, 18 Oct 2010 05:08:24
In Reply to: Re: [gentoo-doc] Documentation/website in git? by Joshua Saddler
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