Re: CVS is the `released version'

[David Kastrup]

"Ken Manheimer" <address@hidden> writes:

> (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.

I don't know how often I will have to repeat that point: a central
repository requirement is something which is not going to work out
well.  Packages should be able to know where they originate by
themselves.

Anyway, to get a view of what XEmacs uses, here are the defaults for
the user <URL:http://www.xemacs.org/Documentation/packageGuide.html>,
and here for the package contributor:
<URL:http://calypso.tux.org/pipermail/xemacs-beta/2005-June/006129.html>.
The latter link illustrates (and defends) some of the problems
stemming from a central repository approach.

What is not mentioned in there is that the administrative hurdle
(become XEmacs developer with CVS access) for package maintainers is
exacerbated by non-trivial packages in CVS having a completely
different file layout and control files that are not present in the
finished package.

A copyright assignment requirement would probably be a similar hurdle
as the CVS access is, however, since there is no way that a third
party can do the copyright assignment (and third part CVS
maintainenance of a package is quite common for XEmacs packages), it
would at least not intrpduce a division of forces for those package
that make it into a central repository.

And we also want to avoid a _technical_ hurdle, namely the CVS
(=source, except in XEmacs terminology) form of a package having a
different structure from the final package, a structure that can't be
mapped onto the other without the help of scripts and files specific
to the package in question.

That's another place where we don't want to go if we can avoid it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum