On Tue, 19 Jan 1999, Peter J. Braam wrote:

> Where will the limits lie?  I think that I can see that we can scale
> Coda to approximately 500,000 files over the next year (the size of
> the files is irrelevant). There will be implementation changes needed
> for that which are not backward compatible, and you'll need a kernel
> patch on the servers.  Getting beyond that would require major
> rewrites.

What is the current limit?

Unless someone thwacks me on the head to the contrary, I am considering
having the school I attend experiment with using coda in a 'production'
environment. Now obviously we are going to wind up having some problems,
but I am satisfied enough with the usability of 5.0 to see it becoming
useful in a real world environment. The current /home has 90k files, and I
expect that will perhaps double within a year, in which time frame I hope
"big coda" will be released and migrated to ;-) I'm pretty sure this 180k
files is well within the limit of 250k files that the present server
supposedly supports, though.

> What we really need is a lot of people that can dedicate space on a
> 2GB server to run Coda every day.  Hopefully you can write some
> testing software for us, or get a few people to use it and send
> detailed bug reports.  If you can fix the bugs, even better.

Do you have a bug tracking system online where people can take a look at
what the current problems are?

Oh wow, I just looked at your web site, there is a bug system online. If I
missed the announcement of this on the mailing list, I am sorry... Is
there an e-mail address that people can use instead of the web submission
form? I know bugs_at_gnome.org used to go right into the gnome jitterbug
'incoming' folder.

> We'd like to be a real bazaar, but so far it has proven a little
> difficult.  Part is Coda's messy and complex code (it's getting better
> though), probably we are doing other things wrong - and if you have
> suggestions how we can improve things let us know

I would like to offer to set up an anoncvs server so everyone can stay
synch'd up with the source tree. Phil could probably take care of the
whole deal, as long as the AFS volume is publicly accessable, and I prod
him enough... :)

This would allow people to submit patches that they knew were relevant
against the latest source tree, plus ensure that they weren't reporting a
bug that had already been fixed.

> , and then hopefully you do it for us (perhaps with our help). Please
> help us by using it and getting involved in the problems.  We will
> continue to work as hard as we can, but without a bazaar, Coda will
> not become your 20G server ever.

Are there any specific things that people can do to help? People have
limited hacking cycles, and if there were some smaller tasks that looked
approachable, I think that would get people involved.

In the GNOME project, we try to keep a detailed TODO list online
(http://www.gnome.org/devel/gnome-libs-task-list.shtml). This helps people
find things to do when they have two hours free in the evening. Also very
valuable is the anoncvs/daily snapshots stuff, which lets people keep up
with the latest development, and feel that progress is being made. (The
attraction of novelty, if nothing else :)

Because I have other obligations, I can't promise to spend every day
testing or coding, but if there are enough small tidbits to be worked on,
it's a pretty sure bet that I will eventually get around to doing one of
them :)

Are you looking for people to maintain a TODO list or the web pages? Are
there any other administrative tasks that you would like to offload so you
can focus on the code? Any other specifics? What are your plans and
timeline for coda development in the future?

Hope this helps,
-- Elliot
"In film you will find four basic story lines. Man versus man, man
 versus nature, nature versus nature, and dog versus vampire."
    - Steven Spielberg