1 |
On Tue, Jun 05, 2012 at 12:36:04AM +0200, Michael Weber wrote: |
2 |
> On 06/04/2012 03:25 PM, Brian Harring wrote: |
3 |
> > While I do grok the potential issue of someone being a hog |
4 |
> > (specifically via blasting commit by commit rather than building up |
5 |
> > work locally, then pushing it in chunks), frankly... I'm not that |
6 |
> > concerned about it, and would rather deal w/ it if/when it occurs. |
7 |
> > The nature of our commits for the most part are standalone from |
8 |
> > others- that's not true of the kernel/mozilla, thus why I don't |
9 |
> > think their issues are necessarily ours. |
10 |
> True. |
11 |
> |
12 |
> We already have maintainers and herds as responsible (sole editors) |
13 |
> entities for locations (packages). |
14 |
> |
15 |
> But, we have arch teams editing ebuild/KEYWORDS, which alters |
16 |
> Manifest/EBUILD lines. Resulting in potential clashes (not |
17 |
> fast-forwardable), if the herd or maintainer does bumps or cleanups. |
18 |
> |
19 |
> Will these Manifest lines (and the arch team inflicted Manifest changes)? |
20 |
|
21 |
Converting to git, we'll switch over to thin manifests- they're *just* |
22 |
the checksums for the distfiles, no need for the rest since git |
23 |
already provides that verification implicitly. |
24 |
|
25 |
That just leaves conflict w/in ebuilds, which is a valid "the dev |
26 |
needs to deal with this themselves" scenario imo. |
27 |
|
28 |
|
29 |
> According to robbat2 data (gentoo-commit tarball) we have ~400k |
30 |
> commits in gentoo-x86 (w/o proj,xml) in 4.7 years, that's 6.2 per hour |
31 |
> averaged. |
32 |
> But I've to look into the data to see trends (# developers, daylight). |
33 |
|
34 |
One thing to note- that's *individual* commits, and probably a mildly |
35 |
jacked up number due to the double tap requirement of commiting |
36 |
manifests to CVS. |
37 |
|
38 |
What I'm driving at is that there's a difference between |
39 |
commits/revisions, and pushs; I expect our push rate to be less; I'd |
40 |
be surprised if we're doing 1:1 commit/push rate. The conflict rate |
41 |
should be less painful for people in that light, or at least has been |
42 |
in my experience thus far. |
43 |
|
44 |
|
45 |
Btw, good catch on package.mask. Hhadn't thought of that, that |
46 |
*will* be the most contentious point. That can be dealt w/ via |
47 |
having git on portage-1 profile format so we'd have package.mask as |
48 |
directories (which Ciaran will validly hate, and I won't like |
49 |
due to having to write the portage-1 -> PMS translater for |
50 |
rsync distribution), or coming up w/ a different way to split the |
51 |
commits across multiple files, rather than a single. |
52 |
|
53 |
That's assuming package.mask becomes a significant conflict point |
54 |
also. Frankly I'd rather deal w/ that problem when it arrises, rather |
55 |
than trying to optimize for it now. |
56 |
|
57 |
~harring |