| 1 |
On 23/11/05, Lance Albertson <ramereth@g.o> wrote: |
| 2 |
> Daniel Ostrow wrote: |
| 3 |
> |
| 4 |
> > Lance: |
| 5 |
> > |
| 6 |
> > I know this is a far cry from what you are proposing, and I understand |
| 7 |
> > that the present CVS server cannot handle this sort of load but I |
| 8 |
> > believe that this was the original intention at least...someone correct |
| 9 |
> > me if I am wrong. |
| 10 |
> |
| 11 |
> One of the issues we had with direct cvs access is managing all of the |
| 12 |
> AT accounts. If we're talking 50-100 ATs, that increases our user |
| 13 |
> account management load by a lot considering we only have 300 developers |
| 14 |
> right now. The other reason is of course with load on lark itself. We |
| 15 |
> can only do so many concurrent cvs up's of the full tree and adding this |
| 16 |
> many users concerns me alot with that aspect. |
| 17 |
> |
| 18 |
> As what kurt said in a followup to this email, If we can nail down that |
| 19 |
> the primary need of the GLEP is quick access to changes, that will help |
| 20 |
> us a lot in figuring out the logistics of the issue. |
| 21 |
> |
| 22 |
> I know pylon had talked about the newer cvs allowing for a virtually |
| 23 |
> 'live' update to another cvs box via a commit hook, but he's been rather |
| 24 |
> busy lately and hasn't had a chance to work on that. I think that has |
| 25 |
> the best hope down the road of resolving this GLEP. I would just like to |
| 26 |
> keep the management of lark to the minimum if at all possible, so for |
| 27 |
> now I would prefer a restricted rsync module or cvs box that gets |
| 28 |
> updated every X minutes. |
| 29 |
> |
| 30 |
> Cheers- |
| 31 |
> |
| 32 |
> -- |
| 33 |
> Lance Albertson <ramereth@g.o> |
| 34 |
> Gentoo Infrastructure | Operations Manager |
| 35 |
> |
| 36 |
> --- |
| 37 |
> GPG Public Key: <http://www.ramereth.net/lance.asc> |
| 38 |
> Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 |
| 39 |
> |
| 40 |
> ramereth/irc.freenode.net |
| 41 |
> |
| 42 |
> |
| 43 |
What about finding out how many ATs are going to be using it at the |
| 44 |
start and limiting the amount of ATs with access to <40-50 until |
| 45 |
either a new way for access has been decided on or new equipment has |
| 46 |
been brought it. Currently I wouldn't need it because I am without |
| 47 |
amd64 equipment until after equipment. |
| 48 |
|
| 49 |
George |
| 50 |
|
| 51 |
-- |
| 52 |
gentoo-dev@g.o mailing list |
Archives