Re: Documentation/website in git?

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