Re: [Chicken-hackers] Distributed egg repo proposal

[Christian Kellermann]

Hi all,

* Peter Bex <address@hidden> [110303 09:32]:
> I've written up a proposal for switching our egg repository to
> a distributed type of deal:
> 
> http://wiki.call-cc.org/distributed-egg-repos
> 
> Since many users have indicated they are very much fed up with
> svn and would prefer to use $FAVORITE_VCS  (and some of our existing
> developers are already doing so, mostly ignoring svn) I think this
> deserves some serious consideration.

I have carried around various thoughts on this matter for a long
time now. I hope they are ready for public consumption.

Let's restate the pro's of Peters approach:

* Proper usage of version control
* Distribution of the permission bottleneck
* Lower barrier of entry
* Reducing checkout and repository size

and the cons

* Broken links & dependencies
* Documentation
* Additional complexity

I would like to adress some fears people already expressed and
propose a a bit more than Peter did in his original proposal:

Previously some folks mentioned that a DVCS means looser coupling
between the 'official' egg repo code and the DVCS contributions
with all the risks of being unmaintained, unreachable, converted
to python etc...

In my little world this can be caused by:

* maintainers leaving
* stalled development (either WORKS FOR ME or obsolete-d-by-next-hype)
* collapse of infrastructure, (sourceforge changed policies, github
sold out, etc)
* death of domain (spammers taking over, unpaid bills,...)

I think the only way to get a grip on these issues is to have a
centrally maintained repository or trust other parties to ensure
the availability of code.

Documentation: At least at the moment I cannot see a drawback in
that in either solution. Either the author cares and provides
documentation or he doesn't. We do have poorly documented eggs in
the repo at the moment and we also received nice documentation from
contributors with external main repositories.

Additional Complexity: This is also a no brainer, whichever way we
decide to go, we will have to change things in the long run. Either
to adapt to the larger SVN tree or to the new scheme. Both may be
done without breaking existing stuff (apart from path changes of
course).

So I think the only remaining hard drawback is the looming doom of
unmaintained code that I as another egg author would build on my
own egg or depend on it as a application developer in my job.

So why bother?

Because the good parts are really good.

Lower entry bars is great! Not restricting people to a certain
workflow is also great. I don't mind the checkout size of the repo
that much, maybe we can find ways to deliver a functional checkout
with some technical helper?

But the first two points are the key. I am just not sure if the
solution is the right one because of the BROKEN LINKS[tm] scenario.

What about the following sketch of an alternative:

 - Abstract the installation process through the henrietta script
 as proposed. (I really like this idea).

 - Automatically *mirror* the contributed archives on call-cc.org,
 maybe after the code has passed N salmonella rounds of master and
 experimental branches.

 - Keep the documentation in the wiki as it is.

I envision this mirroring stuff simply as a means of the contributor
adding a repo url or something similar to the repo with a branch
of it being defined as  'release' or 'stable' code. Then the magical
script will pull it in and schedule it for salmonella, mailing back
all rrors it finds. After some rounds it is accepted and actively
mirrored and registered with henrietta.

Of course this also comes with a price tag in terms of our time and
effort to get it up and running smoothly. I do think this allows
us to combine the best of both worlds though. From perliminary
research I beleive that quicklisp works according to this principle.
And if there is something new in the lisp library world, it is a
central archive and distribution channel. We already do have this
advantage, so why not open this up a little for decentral contributions?


Thanks for reading this far. I hope I was able to give you a coherent
dump of my thoughts on this.

May it fertilize the further discussion.

Kind regards,

Christian