On Fri, Feb 20, 2009 at 08:21:23AM -0600, steve(a)lonetwin.net wrote:
a. Naming pacakges is going to be tough, because books have long titles,
such as cory doctorow's, do acronyms make sense ?
This is not an easy issue, because, contrary to software there is no
convenient name that upstream choosed. So the packager is left
with too much choice and contradictory objectives.
* short names are better
* content needs to be disambiguated from software and other content with
different medium and same title
* the name should allow to find which content it is as best as possible
Other issues arise, what about different languages, different formats?
b. Version numbers do not make sense for content that is not
versioned
If the author has a versionning scheme that looks ascii ascending lets
use it. Otherwise I think that the following would work
Version: 0
Release: 0.X.YYYYMMDD
with YYYY year, MM month and DD day (I'd do the same for a software
without version, and it is indeed what I used for uread) for the document
date of publishing, or of access if publishing date is not known.
c. How does one treat remixes (ie: content that has been modified and
re-released by someone else). This is going to be different than
software, because, the ^upstream^ are more likely to *prefer* the forks
(so to say) to live side-by-side with the originals than discourage it.
Not an issue here, and it is the same than with forks that are both
interesting (like xemacs and emacs).
d. Is it acceptable to distribute content like this:
http://ghosts.nin.com/main/order_options
where although the content is licensed under a share-alike license[1],
the actual way to get the content is to provide an email where a
'one-time download' link would be sent. So, that implies, we get around
the spirit under which the content is being shared (assuming the sole
intention of this policy was to track downloads).
Not an issue. At least ncarg (or ncl) was like this and is in fedora.
I think that the NonCommercial clause makes it not suitable for a
fedora content repo, however. (not modifiable would be fine, in my
opinion, but not noin commercial).
My Todo list was mentioned under the assumption that this is not
something Fedora would see as a good fit 'within' the distribution
itself.
I'd be very pleased if my assumption is wrong.
I think that there are books that fit in fedora and not in a separate
repo. For example, the 'maximum rpm book', but also books that
explains how to configure servers, or the svn book
http://svnbook.red-bean.com/
Also videos closely realted with fedora should in my opinion
be directly in fedora, like videos explaining how to use a given
application.
Books about programming are less obvious candidates to be directly
in fedora, but still good candidates in my opinion.
--
Pat