> 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 _______________________________________________ Chicken-hackers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-hackers
