1 |
On Thu, 16 Sep 2010 20:46:52 +0400 |
2 |
Peter Volkov <pva@g.o> wrote: |
3 |
> Hi, guys. While there is some job required to move portage tree |
4 |
> into git it looks like moving documentation and web-site could be |
5 |
> done much easier. Are there any plans to move on git? Was anything |
6 |
> done in this direction? This will simplify translator's job as we |
7 |
> are planning to use git that makes commits faster and allows us to |
8 |
> ease workflow. |
9 |
|
10 |
I've been talking to Robin (robbat2) off and on about moving to git |
11 |
for more than a year now. From what he tells me, it's a simple thing |
12 |
to switch our website and docs over to git, on the infrastructure |
13 |
side at least. |
14 |
|
15 |
There aren't too many changes to make to the docs scripts that gorg |
16 |
runs, and there's no difference in server load or required storage. |
17 |
|
18 |
However, we would need to completely rethink our workflow. I jotted |
19 |
down some notes many months ago; I still have some of 'em: |
20 |
|
21 |
- Bugzilla changes for drafts and patches? How much would still be |
22 |
posted there when we could just have people send pull requests to |
23 |
their git clones of our master? |
24 |
- What about branching? Needed for what we do? What about the |
25 |
handbooks? (We used to always do something like that for the |
26 |
networkless handbooks, which is partly why we no longer keep |
27 |
versioned handbooks around.) |
28 |
- Reverting commits should be simpler. CVS sucks for reverting |
29 |
mistakes. |
30 |
- Internal doc formatting: should we abandon the <version> scheme, |
31 |
since we can just use git commit hashes? It would reduce the manual |
32 |
bumping we do (and forget to do). How would that work with git |
33 |
history? |
34 |
- Speaking of history: we'd need a way to carry over CVS history to |
35 |
Git history; we absolutely CANNOT lose the merge/update history, or |
36 |
all the docs that are in and out of the CVS "attic." Often enough |
37 |
we get bugs asking for additions or changes, but it's been settled |
38 |
and explained in previous commits and CVS logs. |
39 |
- Cloning and initial checkouts could be quite nice for translators |
40 |
and English devs alike; merging branches and managing contributors |
41 |
would be much more flexible and fine-grained. We could host all |
42 |
clones on gentoo's git, or even if we continue to have multiple |
43 |
separate repos, git makes it easy to pull and merge those changes |
44 |
regardless of location. |
45 |
- What else would translators need? |
46 |
|
47 |
Git access will ultimately require "gitolite" to be ready. Gitolite |
48 |
is a perl-based replacement for gitosis-gentoo, which serves up all |
49 |
our git trees ATM. |
50 |
|
51 |
I wouldn't mind moving to git, but I already have some limited |
52 |
experience using it for a year or so. Not all of our contributors are |
53 |
familiar with it, and even I need to learn more about how git works, |
54 |
since it's so different from CVS. I imagine we might have some |
55 |
holdouts who don't want to move from CVS at all, so now's the time to |
56 |
speak up. What does the rest of the GDP think about moving to git? |