On Tue, 2005-11-22 at 17:56 -0600, Lance Albertson wrote: > Marius Mauch wrote: > > On Sun, 20 Nov 2005 09:32:55 +1100 > > Ben Skeggs <[EMAIL PROTECTED]> wrote: > > > > > >>Anyway, the most important reason for the GLEP (IMO) is giving AT's > >>r/o access to CVS. When working on bugs, it's always fun to find out > >>that the problem has already been resolved and just hasn't made it to > >>your local rsync mirror yet.. > > > > > > Out of curiosity, what's the more important aspect of r/o cvs: > > - more up to date > > Not necessarily true. We would not have the anon cvs access from our > primary cvs server. It would be synced on a regular basis to a separate > box. The newer cvs (which isn't on lark yet) may give us capabilities to > have a more 'live' cvs anon system. But as of now, the best infra can > provide is 30 minute updates. I don't want to poll the cvs more than > that to keep down the load. > > > - easier selective updates > > Yup, that's definitely a plus. >
And herein I think lies some confusion. Personally if I were an AT both would be important but more to the point the "more up to date" issue would be the most important. I think that there is a need for the ATs to be able to work in direct conjunction with a dev, an AT catches an error, a dev fixes it in CVS using a *well tested* patch, an AT does a `cvs up` and retests to try and catch *other* errors all within a matter of *single digit* minutes. This is a very powerful tool, rather then what they have to do now which is either wait for it to hit the rsync mirrors, a dedicated rsync mirror, a dedicated anoncvs box, or e-mail the ebuilds (and patches) back and forth. Note the two highly stressed things up there...this should not be used so ATs can vet patches (wither to ebuilds or to source), the patches should be well tested long before they reach our tree... Lance: I know this is a far cry from what you are proposing, and I understand that the present CVS server cannot handle this sort of load but I believe that this was the original intention at least...someone correct me if I am wrong. I think that this issue has to be nailed down *before* we get any further in discussion. -- Daniel Ostrow Gentoo Foundation Board of Trustees Gentoo/{PPC,PPC64,DevRel} [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list