| 1 |
On 11/19/05, Kurt Lieber <klieber@g.o> wrote: |
| 2 |
> On Sat, Nov 19, 2005 at 05:06:15PM +0000 or thereabouts, Kurt Lieber wrote: |
| 3 |
> > For instance, the way GLEP 41 suggests doing r/o cvs is not going to work. |
| 4 |
> |
| 5 |
> So, in the interests of trying to find a solution to this particular |
| 6 |
> problem... |
| 7 |
> |
| 8 |
> As I understand the GLEP, the main requirement here is to give the arch |
| 9 |
> testers faster access to the ebuilds in CVS. Is this accurate? |
| 10 |
|
| 11 |
This is the main idea behind it I believe. |
| 12 |
> |
| 13 |
> If so, is there any reason we have to use CVS? Lance and I are both |
| 14 |
> concerned about the extra load that another 50-100 people (extrapolating |
| 15 |
> from the 20 folks that amd64 says they have currently) will place on |
| 16 |
> cvs.g.o and I'd rather break this out onto a separate server. |
| 17 |
|
| 18 |
Funy, I was just pondering that myself... is authenticated rsync |
| 19 |
really possible? I was thinking about some sort of on-the-fly access |
| 20 |
list updating based on a daemon running on AT's computers, that sent |
| 21 |
current IP.. but that sounded kind of messy, I suppose you are better |
| 22 |
at figuring this out than I am, though :) |
| 23 |
|
| 24 |
The only downside to this that I can see would be the lack of |
| 25 |
history... FEX an upgraded -rX ebuild breaks something, I could test |
| 26 |
against previous -rX's in turn to find out exactly which broke it, and |
| 27 |
other history like stuff. This may or may not be necessary/helpful, |
| 28 |
hard to say without it having happened :) |
| 29 |
|
| 30 |
Thanks for coming back and thinking about the implementation, |
| 31 |
reguardless of which way its done. |
| 32 |
> |
| 33 |
> One proposal being discussed is setting up a dedicated rsync server for |
| 34 |
> this purpose that a) syncs from CVS more frequently and b) has no ban |
| 35 |
> limits imposed on it. Arch testers would have some way of authenticating |
| 36 |
> to the box and being able to sync as frequently as they wanted to. Current |
| 37 |
> goal is to have all data in this new repository within 30 minutes of it |
| 38 |
> hitting CVS. (current average is about 1 hour) |
| 39 |
> |
| 40 |
> If the requirement is for r/o CVS access to the same CVS server that the |
| 41 |
> pure-blooded developers use (sorry, couldn't resist) then it may require |
| 42 |
> upgrades to our existing server and/or purchasing a new server. |
| 43 |
> |
| 44 |
> --kurt |
| 45 |
> |
| 46 |
> |
| 47 |
> |
| 48 |
|
| 49 |
-- |
| 50 |
gentoo-dev@g.o mailing list |
Archives