Hi, Ivan et al,

On Thu, 2002-07-04 at 10:34, Ivan Popov wrote:
> pity to hear that people are giving up with Coda.
> 
> The reason *might* be in trying to hide the complexity and "make it easy",
> while creating excessive complexity for that purpose?
> 
> My own experience is that for such a complicated service as
> coda server or client, it is very hard to make a package surviving
> installation in very different circumstances. It is even worse when
> trying to upgrade.
> 
> It costs a lot of time to make a reasonably "bulletproof" package for one
> system/distribution. Multiply with distributions versions and
> variations...
> 
> I would think Jan could provide the functionality but rather someone else
> should maintain packaging. It is a big work and it demands a deep
> knowledge of both the product and the system and distribution policies and
> tools. Not that Jan lacks that knowledge, he lacks the time.
> 
> > I got the coda RPMs, but decided it was just not worth the trouble
> > to try to deal with all the version incompatibilities.
> 
> Exactly.
> 
> > Surely it wouldn't be that difficult to create contemporary RPMs?
> 
> I am not sure how good RPMs can be done.
> 
> I have recently looked at commercial DCE for Linux packaging (RedHat rpms)
> and well, for us it is unusable out of the box, we have to run homegrown
> scripts to configure it. The reason - too many assumptions that had to be
> made to make the installation "easy". Instead, they made it impossible.
> 
> I think Coda is in almost comparable range of complexity.
> 
> I do not like the fact that Coda configuration scripts try to contain a
> lot of hooks and heuristics about different environments they have to be
> functional in. It does not belong to the functionality and it makes it
> harder to understand Coda. Then when it breaks, it is treated as "Coda
> fault" :( [Even a well configured] computer system may still break scripts
> that contain too many assumptions and try to suit any of 50 "known"
> environments. In the real world there are more anyway.
> 
> I think simple *system-independent* configuration interface to the coda
> tools complemented by *documentation* what the things mean
> would make the install success ratio higher than trying to wrap the things
> down (into some "artificial intelligence" implemented in /bin/sh or perl).
> 
> Let's state explicitely:
>  - these daemons have to be started in this order
>    and taken down in that order
>    (or - this script has to be run to start, that one - to stop, but do
>    not build knowledge about the system(s) into these scripts)
> 
>  - these binaries are using following config files and libraries
>    (exact list)
> 
>  - these choices (pointer into configfiles) influence the following...
> 
> Then let the local sysadm arrange the placement, startup and shutdown, he
>    knows the concepts, what processes and libraries are...
>    or am I too optimistic? :-)
>    ok, let "distribution packager" arrange that, anyway it does not
>    belong to Coda itself.
> 
> The above might work better that scripts that make it right in 90%
> cases but contain so excessive logic that it is hard to understand and
> fix them.

I started building packages for Coda for Gentoo (http://www.gentoo.org/)
and had the client side of things running after half a day's work.
Gentoo's packages ('ebuilds') are a bit different from RPMs and Debs in
that they are compiled in situ. Which of course gives you a bit more
freedom in some spots and a lot of headache in others. Anyway, I was
just about to start working on the server side of things when I learned
of the volume size limitations, which basically made Coda unusable for
my current project. (I am looking to replicate up to 1Tb across 2-3
servers with 10 clients.)

The relative difficulty of setting up Coda is something that has to be
addressed to give it mainstream credibility, but to be frank, I think
that Coda is pretty easy to install as it is. Although docs and code are
a bit out of sync, with some experience and hard work you can get
everything up in a good day's time, even starting from scratch. For less
experienced people it may prove more difficult, and the lack of
pre-packaged installs leaves quite a few people stranded.

However, I think that the more serious issues of performance and
scalability are things that have to be adressed before one could even
hope for Coda becoming more than a "closed group of happy admins"
scenario. I really have faith in Coda as it is being presented; full
replication, disconnection and trickle updates is just really, really
cool and what Linux needs to be taken seriously (not to speak of kicking
Veritas and such where it hurts), and there are no good alternatives out
there at the moment. However, if these issues are not addressed, and
soon, some other, maybe less capable solution will take over the show.

Which leads me to ask - how many are actually developing on the core
setup? Is an open developers' group an alternative, or is it being lead
from the university's side? If "open coding" is an alternative, what
moves have been made to try and bring outside developers into the core
of development? Please get me right here - I am NOT questioning the
ability of present and past developers, who have already produced a
brilliant piece of code, but I see a capacity problem coming up (As Ivan
pointed out.)

I would be more than happy to provide time and programming abilities (to
the extent my qualifications would be useful to the group & project),
ie. in helping to wrap things up into packages for the distributions
that I know and work with (mainly SuSE and Gentoo). If I could be of any
assistance to any core work, please let me know.

Best regards
Jan Bruvoll