| 1 |
Brian Harring wrote: |
| 2 |
> 1) We need a thin manifest -> thick manifest converter. |
| 3 |
|
| 4 |
This needed all of two lines of code to be added to portage, thanks |
| 5 |
to your work teaching portage about thin manifests. |
| 6 |
|
| 7 |
http://git.stuge.se/?p=portage.git;a=commitdiff;h=thickandthin |
| 8 |
|
| 9 |
I will rework it slightly per discussion in #gentoo-portage though. |
| 10 |
|
| 11 |
|
| 12 |
> 4) People who strongly know git hooks would be useful; server side, |
| 13 |
> all incoming pushes from devs will have their commits validated before |
| 14 |
> touching the tree- bad validation, commit gets kicked back to them. |
| 15 |
|
| 16 |
The question is what exactly the hooks need to validate? Please spec |
| 17 |
this, then someone can implement. |
| 18 |
|
| 19 |
|
| 20 |
> whoever does this, needs to write it such that the auth backend is |
| 21 |
> configurable (upon deployment, this will be bound into ldap, or an |
| 22 |
> ldap scraped set of data that it'll consult); assume that the auth |
| 23 |
> backend will be user->gpg key level of validation (meaning I cannot |
| 24 |
> take a random commit antarus had against current ToT, and push that |
| 25 |
> on his behalf- robin may disagree on this point however). |
| 26 |
|
| 27 |
What data is available? |
| 28 |
|
| 29 |
You mentioned that gitolite will be used on the server. Is there a |
| 30 |
mapping ( allowed author+committer email address and real name ) -> |
| 31 |
SSH public key identifier already available? |
| 32 |
|
| 33 |
|
| 34 |
> 2) cvs -> rsync pathways being rebuilt to be git -> rsync (reliant on |
| 35 |
> #1 from above, but there is more that occurs there). |
| 36 |
|
| 37 |
Please tell more about what occurs there. |
| 38 |
|
| 39 |
|
| 40 |
//Peter |
Archives