1 |
On Mon, Sep 15, 2014 at 11:50 PM, Brian Harring <ferringb@×××××.com> wrote: |
2 |
> |
3 |
> On Sun, Sep 14, 2014 at 10:33 AM, Rich Freeman <rich0@g.o> wrote: |
4 |
>> |
5 |
>> On Sun, Sep 14, 2014 at 8:03 AM, Michał Górny <mgorny@g.o> wrote: |
6 |
>> > |
7 |
>> > Of course, that assumes infra is |
8 |
>> > going to cooperate quickly or someone else is willing to provide the |
9 |
>> > infra for it. |
10 |
>> |
11 |
>> The infra components to a git infrastructure are one of the main |
12 |
>> blockers at this point. I don't really see cooperation as the issue - |
13 |
>> just lack of manpower or interest. |
14 |
> |
15 |
> |
16 |
> I can't speak for current gentoo infra, but it'd help to think through |
17 |
> exactly who will have RO access to the git repo. |
18 |
> |
19 |
> Trying to have the entire gentoo userbase accessing the repo via git is |
20 |
> going to be resource intensive- if you're intending that, well, start |
21 |
> donating frankly. |
22 |
> |
23 |
> If however you're angling for just devs having git access, and utilizing the |
24 |
> existing rsync mirror, that should be a helluva lot more doable (even with |
25 |
> shitty hardware). |
26 |
|
27 |
I believe that is the proposal here. There would be a dev-only main |
28 |
repository which is where all commits would go. Then there would be a |
29 |
power-user sync repo derived from that, and then an rsync tree derived |
30 |
from that. This isn't all that different from what we do with cvs. |
31 |
|
32 |
Git is pretty easy to mirror, since it is after all a distributed |
33 |
system at its heart. It would probably make sense to do one push/pull |
34 |
from the main repository to the power-user repo, do whatever magic |
35 |
needs to be done with it, and then push out from there to a mirror |
36 |
network, github, wherever. We'd probably want mirrors of both the |
37 |
original dev tree and the one with metadata and such. |
38 |
|
39 |
|
40 |
>> People love to point out linux and its insane commit rate. The thing |
41 |
>> is, the mainline git repo with all those commits has exactly one |
42 |
>> committer - Linus himself. They don't have one big repo with one |
43 |
>> master branch that everybody pushes to. At least, that is my |
44 |
>> understanding (and there are certainly others here who are more |
45 |
>> involved with kernel development). |
46 |
> |
47 |
> |
48 |
> To be frank, I think you're seriously overthinking it and worrying about a |
49 |
> nonissue. Worrying about this while ignoring security enhancements like |
50 |
> requiring signed commits on push is a bit weird to me. |
51 |
|
52 |
So far the discussion in the thread has included the commit signing issue. |
53 |
|
54 |
I tend to agree that commit rate probably won't be a problem after |
55 |
some discussion, as long as we don't require a repoman check 100% of |
56 |
the time in-between pull and push. For a single package that won't be |
57 |
a problem, but doing it at the category/tree level is just going to |
58 |
make collisions inevitable. |
59 |
|
60 |
> One additional point no one has mentioned; when cutting over to git, |
61 |
> afterwards someone will need to go through and rip out all of the cvs $Id |
62 |
> style tags that exist in the tree- depending on how folks are doing the |
63 |
> conversion, it might be worth just jamming that in right off the bat rather |
64 |
> than trying to clean the tree afterwards. |
65 |
|
66 |
I'd suggest that we not go too much further with editing history - |
67 |
consolidating Manifest/package commits did make sense, and the other |
68 |
fixes do as well. I'd prefer not to go trying to remove keywords from |
69 |
the tree during conversion. We've already had all kinds of headaches |
70 |
from keywords as it is (especially with patches/etc). I suggest that |
71 |
we initially convert the tree and leave the keywords in, and we can |
72 |
always clean them up later, either by script or manually. I'd suggest |
73 |
keeping scripting to a minimum guaranteed-safe level (such as just our |
74 |
ebuild headers), and leave it up to maintainers to get any stray ones. |
75 |
|
76 |
In-band signaling is lousy design in this day and age. Oh, did |
77 |
somebody bring up Changelogs? :) |
78 |
|
79 |
> ~ferringb, who was enjoying his retirement very much thank you |
80 |
|
81 |
I appreciate your email - there is a lot of history we can stand to |
82 |
benefit from. I think I have a container set up now that can |
83 |
efficiently migrate cvs->git using your scripts, and I'm just doing |
84 |
some more testing and work to make it fully transportable. From there |
85 |
we just need to figure out where to run it when the time comes, which |
86 |
should be the easy part. |
87 |
|
88 |
I do believe that mgorny was offering to step up to help out with the |
89 |
scripting though. If we have the scripts/hooks needed to manipulate |
90 |
gentoo-x86 to produce the various trees, then I think that |
91 |
transplanting them to infra will not be a difficult next step. Really |
92 |
that part is the part which is most lacking right now, so if a few are |
93 |
willing to step up on this I think we can get somewhere. |
94 |
|
95 |
-- |
96 |
Rich |