| 1 |
On 14/09/14 17:15, Kent Fredric wrote: |
| 2 |
> On 15 September 2014 02:40, Michał Górny <mgorny@g.o> wrote: |
| 3 |
> |
| 4 |
>> However, I'm wondering if it would be possible to restrict people from |
| 5 |
>> accidentally committing straight into github (e.g. merging pull |
| 6 |
>> requests there instead of to our main server). |
| 7 |
>> |
| 8 |
> |
| 9 |
> |
| 10 |
> Easy. |
| 11 |
> |
| 12 |
> Put the Gentoo repo in its own group. |
| 13 |
> Don't give anyone any kinds of permissions on it. |
| 14 |
> Have only one approved account for the purpose of pushing commits. |
| 15 |
> Have a post-push hook that replicates to github as that approved account |
| 16 |
> |
| 17 |
> => Github is just a read only mirror, any pull reqs submitted there will be |
| 18 |
> fielded and pushed to gentoo directly. |
| 19 |
> |
| 20 |
> Only downside there is the way github pull reqs work is if the final SHA1's |
| 21 |
> that hit tree don't match, the pull req doesn't close. |
| 22 |
> |
| 23 |
> Solutions: |
| 24 |
> |
| 25 |
> - A) Have somebody tasked with reaping old pull reqs with permissions |
| 26 |
> granted. ( Uck ) |
| 27 |
> - B) Always use a merge of some kind to mark the pull req as dead ( for |
| 28 |
> instance, an "ours" merge to mark the branch as deprecated ) |
| 29 |
|
| 30 |
C) Ask nicely Github to have an application key and have a pull-request |
| 31 |
bridge to avoid the problem completely. |
| 32 |
|
| 33 |
I'd complete the migration first and discuss this kind of details later. |
| 34 |
|
| 35 |
lu |
Archives