| 1 |
Hi! |
| 2 |
|
| 3 |
On Wed, 30 May 2012, Rich Freeman wrote: |
| 4 |
> On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman <djc@g.o> wrote: |
| 5 |
> > Yeah... this is why I was asking about access to infra to test the |
| 6 |
> > conversion; so far, I haven't had any replies, though. |
| 7 |
> |
| 8 |
> A mock conversion would probably help with creating |
| 9 |
> procedures/docs/etc as well. It is nice to say that we're "just going |
| 10 |
> to use git" but I think everybody has a slightly different picture of |
| 11 |
> how that is going to work. |
| 12 |
|
| 13 |
I recommend having a smallish set of willing alpha/beta testers for |
| 14 |
this. This usually helps with some of the near-edge cases. You'll |
| 15 |
still find a thousand other bugs once things go live for |
| 16 |
everybody. Still, it turns a million into a thousand. It also |
| 17 |
gives you slightly more realistic load test. |
| 18 |
|
| 19 |
> If we could set up an "official unofficial" portage tree in git based |
| 20 |
> on a one-time migration (maybe refreshing it from time to time) that |
| 21 |
> could be a sandbox used to work things out, and it would then be |
| 22 |
> replaced with the official tree. When the official migration comes |
| 23 |
> along we'd already be experts in doing it. |
| 24 |
|
| 25 |
This is a good idea that goes nicely with what I wrote above. |
| 26 |
|
| 27 |
> All we need to do is execute the migration, and just not point the |
| 28 |
> rsync generation process at it. Maybe it won't be perfectly right at |
| 29 |
> first, and that would basically be the point of doing it. Devs could |
| 30 |
> update tools to work against it, and the docs could be written |
| 31 |
> alongside. |
| 32 |
|
| 33 |
The scientist in me wonders how big the dent in productivity |
| 34 |
will be, actually. After all, there's going to be a lot of people |
| 35 |
that will hammer the new setup just because of the New! Shiny! |
| 36 |
appeal. |
| 37 |
|
| 38 |
Regards, |
| 39 |
Tobias |
Archives