Re: CVS is the `released version'

[Ken Manheimer]

On 5/21/07, JD Smith <address@hidden> wrote:

> At the very minimum, an integrated, easy to use capability to update
> assigned, core Emacs packages between releases would be very welcome.

i agree - i think this issue is very important.  from people's
responses in this thread, it's apparent that it's complicated by a few
concerns.  i think the discussion is getting muddied by intermixing of
the concerns, and it would be helpful to explicity distinguish and
address them.  my take:

(1) we are talking about enabling package developers and users to update
    the packages they use incrementally within a major emacs release,
(2) without burdening emacs maintainers with change management chaos,
    and
(3) without reducing the incentive for package developers to assign
    copyright to the fsf.

(1) is the purpose of the thing, and seems quite valuable to me.  it
would reduce the pressure for emacs major releases, or conversely,
reduce the impedence that delays in an emacs major release presents.
those of us that feel confident about the general polish of the CVS
head, and our ability to tackle problems when they creep in, have a
version of this by using an emacs checked out and built form the head.
we get bug fixes quickly, and get to enjoy valuable features and
improvements as they arrive.

(3) copyright assignment incentives could be maintained by requiring
copyright assignment for inclusion of a package in the system.  this
may be severe, however - perhaps it would be enough to require
assignment for inclusion in the default collection, but enable
inclusion of alternate collections?  i think this is the gist of one
of the discussions that tom tromey and richard are having in this
thread.  whatever the choice, it seems like this can be kept as close
to the status quo as desired, and relaxed as much as willing, by
choice.

(2) is the tricky bit.  the situation would be simplest if the update
system is contrived to only allow the entire collection of packages to
be updated at as a whole.  this would mean that package committers
need worry only about interoperation with the current version of other
packages, not with the diversity available.  ("current" would be a
gradually moving target, but at least there would be only one target
at any moment.)  what this would amount to is a finer incremental
release mechanism for the lisp directory, as a whole.  this would be
very like someone following emacs development via the CVS head, with
the addition that the releases could be better controlled to ensure
coherence/integrity, rather than being wherever checkins happen to be.

the cygwin installer for the cygwin gnu/linux distribution presents an
example of another, more intricate mode, which i like.  (gentoo's
portage and debian's apt systems are (much) more elaborate versions of
this mode, the cygwin version has the advantage of a compact, concise
interface.)

in it, collections of package versions are offered together, and the
user has to specifically elect for exceptions from the standard (or
alternate) version collections.  by deliberately choosing the
exceptions, the user is aware that they're departing from the
programmed situation.  we could even have bug reporting mechanisms
note such departures, to at least have the deviance reported.

the question here is how much turbulence would be introduced by
allowing more frequent incremental release of the packages, and
further, more intricate combinations of package versions.  i think
both are worth considering.
--
ken
http://myriadicity.net