| 1 |
On Wed, Nov 23, 2005 at 10:38:39AM -0500 or thereabouts, Daniel Ostrow wrote: |
| 2 |
> And herein I think lies some confusion. Personally if I were an AT both |
| 3 |
> would be important but more to the point the "more up to date" issue |
| 4 |
> would be the most important. |
| 5 |
|
| 6 |
I agree -- this was the main point of the original GLEP. |
| 7 |
|
| 8 |
> an AT does a |
| 9 |
> `cvs up` and retests to try and catch *other* errors all within a matter |
| 10 |
> of *single digit* minutes. |
| 11 |
|
| 12 |
I do question the need for "single digit" minutes. 30 minutes may be too |
| 13 |
much, but I think we could probably live with something in the 10-15 minute |
| 14 |
range. (if folks disagree, please speak up) |
| 15 |
|
| 16 |
> I know this is a far cry from what you are proposing, and I understand |
| 17 |
> that the present CVS server cannot handle this sort of load but I |
| 18 |
> believe that this was the original intention at least...someone correct |
| 19 |
> me if I am wrong. |
| 20 |
|
| 21 |
Anything is possible -- it's merely a matter of how much money we want to |
| 22 |
spend in the process. So far, nobody has really come back and said that |
| 23 |
using CVS, specifically, is a requirement. So, at this point, all options |
| 24 |
are on the table, but the main goal is to provide something that is as |
| 25 |
close to real-time as possible and allows authorized individuals to |
| 26 |
synchronize far more often than the current public rsync mirrors. All this |
| 27 |
is for a targeted group of up to ~100 users. |
| 28 |
|
| 29 |
Can we agree on these requirements? Are there others that I've left out? |
| 30 |
If not, we can start working on an implementation plan. |
| 31 |
|
| 32 |
--kurt |
Archives