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