1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Donnie Berkholz wrote: |
5 |
> And the plan ... |
6 |
|
7 |
Quite! |
8 |
|
9 |
> Daniel isn't pushing much on our end, unless if by pushing you mean |
10 |
> doing things that won't be suitable for us because last I heard, he's |
11 |
> dropping all history from the Funtoo tree. |
12 |
|
13 |
Oh, I hadn't realized he was doing that (it seems a little pointless, if |
14 |
he's still syncing up the main tree every day), although I guess it may |
15 |
be for size limits? |
16 |
|
17 |
> 1. Decide whether the existing tree layout is suitable for and best in a |
18 |
> git world. If not, what is? I have done some thinking about this at |
19 |
> <http://dev.gentoo.org/~dberkholz/git/git_conversion.txt>. |
20 |
|
21 |
This seems to be the same place we were back in November last year. Is |
22 |
this something we should ask the council about, or continue discussing here? |
23 |
|
24 |
There seem to be two front runners, 1 repo/package and 1 repo/tree. The |
25 |
pros and cons are as set out in your file (the flat tree option pros |
26 |
don't seem to outweigh the cons, so I haven't really considered that). |
27 |
|
28 |
I'm still not convinced that splitting everything into 13000+ repos will |
29 |
be easily managable, but I'm open to being convinced. I'd be interested |
30 |
in walking through a user branching an ebuild and giving it to others |
31 |
and it would be good to flesh out exactly how you imagined it working |
32 |
since it raises a lot of questions. |
33 |
|
34 |
* Would rsync still exist, or would everybody use git as their push/pull |
35 |
tree mechanism? |
36 |
* Would user generated ebuilds be integrated into the local git portage |
37 |
tree, or treated as an overlay? |
38 |
* Would this make the existing overlay mechanism redundant? How would |
39 |
it affect the signing gleps? |
40 |
* Would a commit id be enough to easily identify whether an ebuild came |
41 |
from an official repo or a user generated repo? |
42 |
* How would we ensure that the various packages can't be checked out to |
43 |
different times (one package from 6 months ago, another package from |
44 |
yesterday and dependencies between them) or does that not even matter? |
45 |
|
46 |
I think most of these have a solution, but it depends on how you saw it |
47 |
working... |
48 |
|
49 |
For the 1 repo/tree, I had envisaged using git as the transport for all |
50 |
trees, and rsync being ditched. Unfortunately I'm not sure that'll be |
51 |
feasible, since we've now seen the size of a full tree with complete |
52 |
history (1Gb vs 100Mb), and the history's mostly irrelevant for the |
53 |
average user. Having the option to do either is nice (much like using |
54 |
CVS for the primary tree), but I don't think it'll ever be the default. |
55 |
As such from a user perspective, everything stays much the same (the |
56 |
rsync mirrors can merge the stable/unstable git trees if we go that way, |
57 |
although there'll be some manifest jiggery-pokery that might affect |
58 |
signing, so this'd need further thought) and the only bit that'll really |
59 |
change is that perhaps the Changelogs are finally autogenerated rather |
60 |
than being added by the developer. |
61 |
|
62 |
> 2. Decide whether the existing development model is suitable for and |
63 |
> best in a git world. If not, what is? I have done some thinking about |
64 |
> this at <http://dev.gentoo.org/~dberkholz/master_plan.txt>. |
65 |
|
66 |
This looks good to me, I'm particularly keen on the "Gentoo taking over |
67 |
the world" bit... 5;P |
68 |
|
69 |
> 3. Switch to the best layout and development model. |
70 |
> |
71 |
> Issue 3 is the easy one. |
72 |
|
73 |
Hehehe, don't worry, I won't quote you on that in the future... 5;) |
74 |
|
75 |
Mike 5:) |
76 |
-----BEGIN PGP SIGNATURE----- |
77 |
Version: GnuPG v2.0.9 (GNU/Linux) |
78 |
|
79 |
iEYEARECAAYFAkl6cV8ACgkQu7rWomwgFXrVQwCdE8wFMgEg+FRpDf3COq/FYkcT |
80 |
4koAn3vgT/16trq1hRT5tqIGIvSYSGar |
81 |
=Rhzn |
82 |
-----END PGP SIGNATURE----- |