Welcome to the Jungerl!

[Luke Gorrie]

Mikael Karlsson <mikael.karlsson@REDACTED> writes:

> 2. Some libs, like xmerl,  has a later version in another cvs repository 
>     under sourceforge. How will they be kept in sync? What happens
>     if anyone updates the one under jungerl. Will the admin of the other
>     one see to it that they are in sync, or shall we expect them to diverge,
>     or shall they all go under the jungerl tree?

I hadn't realised that xmerl was already on sourceforge. Which project
is it in?

We need to be thoughtful about divergence, and if necessary have
special conventions if a program is mostly developed outside the
Jungerl. I don't think this is too hard, we already do it with Yaws
here - it's in our CVS tree, but we hack it on sourceforge and then
import.

The really great thing is how well we can avoid divergence of programs
within the Jungerl, by always being able to make them consistent. For
example, if you need to make an incompatible change to a library in
the Jungerl, you can update the programs that use it at the same
time. Very nice!

In this way I think the Jungerl will reduce divergence in general. I
was already distributing different copies of the XMLRPC and S-Lang
applications bundled with my programs, because it was too much of a
pain to have them separate - I didn't want to make Klacke do a new
release of the S-Lang application every time I add a little binding
for Ermacs. Thankfully, when I imported Ermacs and enfs to the
Jungerl, I was able to unbundle these programs and kill the
divergence.

In any case, for the Jungerl itself we have a clear First Commandment:

  When a Jungerl program depends on other programs, they should also
  be included in the Jungerl.

So it's definitely appropriate to have a copy of xmerl in the Jungerl,
because the XML-RPC application depends on it - as I'm sure new
programs will. BTW, when I added xmerl, I set a tag in CVS, so if you
want to know how the Jungerl copy differs from XMERL 0.17, you can do:

  cvs rdiff -u -r XMERL-0-17 jungerl/lib/xmerl

(The exception is the Makefile, which actually is Jungerl'ified in the
tagged version.)

In general I bet that increased hacking and user-contributing will
make the risk of divergence from non-jungerl programs worse, but in
this case, worse *is* better! [1]

Cheers,
Luke

[1]: Worse Is Better: http://www.dreamsongs.com/WIB.html