[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] call for repository/chicken-setup organization pla
Re: [Chicken-hackers] call for repository/chicken-setup organization plans
Tue, 26 Feb 2008 18:55:12 +0900
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
I think the current repository layout could use a slight tweak:
create a symbolic link /release/current that points to the current
major release, and (if possible with SVN) lock the older release/x
branches, so they cannot be modified. If there is a need to modify
eggs in an obsolete release/x branch, that should be accomplished with
patches. (Maybe create a writeable release/x/patches directory once
release/x is frozen?) Apart from that, I don't like overly elaborate
solutions -- look at the PLT module system, or R6RS. Better keep it
"felix winkelmann" <address@hidden> writes:
> I'm looking for proposals about how to find the ultimate repository/packaging
> combination, or better: what could we do to keep a central, revision
> repository of chicken extensions, manage chicken+extension interdependencies,
> keep users of historical chickens safe from featurecreep, etc. This influences
> usage, development, installation, backups, maintenance and many other things,
> so is really critical and should be well thought out.
> It would be cool if, instead of "hey, this would be nice:..." or, "but
> is must support
> signing of packages!", we could gather somewhat more elaborate proposals
> that try to specify details instead of just handwaving particular issues away.
> I don't think any existing packaging system addresses our needs - we should
> something chicken-specific, to have maximal freedom to adapt it to the
> of this implementation and community development style (-> chaos ;-).
> Please help!