Re: [Chicken-hackers] Distributed egg repo proposal

[Felix]

> I've written up a proposal for switching our egg repository to
> a distributed type of deal:

Hello!

Thanks again for the thorough proposal. I see that you have put a lot
of thought into it and I also believe to understand your motivations -
it should be as easy as possible for someone to create and maintain an
egg, ideally with the VCS of choice.  I personally am quite happy with
svn, even though merging is painful sometimes (But I am not a
sophisticated VCS user, I quickly get annoyed with tools that try to
force any kind of workflow on me. Commit history I find mostly
uninteresting, I just don't want to lose work).

The current system works and is arguably quite reliable. There are no
broken links, and we can do emergency repairs (like trivial syntax
errors in some deep dependency's .meta file) anytime. Being
centralized, there is always one true HEAD, and having tools like
salmonella running over the whole repo is easy. Users will generally
not be interested in commit-history or where the stuff is located,
they just want to access eggs - anytime, with up-do-date dependencies.
Everything maintained and always available. With Alaric's mirror, we
even can cope with server outages. Doing "disruptive" updates (say, a
new release branch) can be done (sort of) "atomically".

Being "distributed" just for its own sake doesn't buy us anything.  WE
DON'T WANT BROKEN LINKS. As you correctly point out, a non-existent
deep dependency will be horrible indeed (catastrophic, actually).  How
to avoid broken links or missing eggs without a centralized repository
I can't say.

Having the egg tree in a git or hg repo would be nice (well, for those
that want it, of course). How to map the current layout to (say) git,
I don't know. Making it scale is another thing. Currently, eggs can be
checked out separately, which should be fine for most egg
maintainers. Having a working copy of a whole egg tree or even the
whole repo is not strictly necessary. There are tools and
VCS-extensions that provide some support for moving history from one
VCS to another, so it should be possible to develop in one VCS and
then push changes to the central egg repo is possible as well (I don't
deny that this may be awkward).

If people are uninterested to move eggs or egg releases into our repo,
that is of course bad, and making things easy for real or potential
contributors is important. What about having a mechanism for
automatically importing/updating foreign repos into our tree? Using
the mechanisms you describe, not for individual egg accesses (by
users, funnelled over henrietta), but for grabbing releases, updating
the repo and tagging? That way we could have the best of both worlds:
an egg maintainer doesn't have to bother with our repo and can just
happily develop, while THE SYSTEM checks for new releases (tags or
better: changed release-info files) and pulls the changes. The
complexity would be under our control and centralized and the hassles
of handling all sorts of VCSes could be dealt with in a central place.

So, my opinion is: the current situation is allright for us, good for
the user, but mildly inconvenient for some developers. Making things
more convenient is something I can understand. But, I must insist on
one thing: no broken links. never.


cheers,
felix