| 1 |
Your idea is a step in the right direction, but the ideal config would |
| 2 |
have a top level portage.git with sub-modules for each category, as well |
| 3 |
as for eclass, licenses, profiles and scripts. Each category.git should |
| 4 |
have sub-modules for each package therein. |
| 5 |
|
| 6 |
Within the profiles.git it *might* be reasonable for each directory in |
| 7 |
arch/ also to be a sub-modules. Or not. That should be dicussed. |
| 8 |
|
| 9 |
And the bureaucracy should be minimal. Adding, changing or removing a |
| 10 |
submodule from its parent repo should only require a call for consensus |
| 11 |
among the devs, and not be pushed through a small set of devs on some |
| 12 |
given team. |
| 13 |
|
| 14 |
It may also be useful for the process which generates metadata/ to push |
| 15 |
out to a repo, too, just before syncing out to the rsync mirrors. |
| 16 |
|
| 17 |
Having each package in its own repo is a great idea. But a simple |
| 18 |
recursive git pull to update the whole thing is highly desireable. |
| 19 |
Git submodules fit the bill perfectly. |
| 20 |
|
| 21 |
This would require re-doing the cvs→git conversion, but it’d be worth it. |
| 22 |
|
| 23 |
-JimC |
| 24 |
-- |
| 25 |
James Cloos <cloos@×××××××.com> OpenPGP: 1024D/ED7DAEA6 |
Archives