[admin] project-creation request for common-lisp.net - tioga project
Sean Champ
gimmal at gmail.com
Sun Aug 6 00:02:18 UTC 2006
Hello,
I would like to request that a project would be created at common-lisp.net.
Here is summary on the immediate goals of the project:
- ultimately, to make a Linux distribution -- deriving it on Debian (and
possibly, on Ubuntu, and maybe, on Mepis, there's a little chain across how
those two are derived, and it anchors, at a point, on Debian) -- for the
purpose of developing and distributing an "out-of-the-box" Common Lisp
environment, designed as to be so, and distributed on a Linux OS.
other operating system kernels may be supported of the project.
Directly of the Debian projects, there are already at least two Debian
distributions, made for BSD-area kernels -- one of which uses one kFreeBSD
(?) as a kernel, and the other, it uses NetBSD. As I recall, there was a
distribution in regards to BeOS. Speaking by experience, Debian packaging may
also be supported for QNX hosts. (I mean no offense to the QNX developers.
For a developer familiar with Debian conventions, it could be easier for that
developer to use Debian packaging, contrasted to to the QNX packaging
system.)
- To gather, to develop, and to draw focus to a number of 'baseline libraries'
for the Common Lisp environment -- one of which would be the SSC project, I
observe, recently added to common-lisp.net.
I understand that the SSC project would serve as a premier,
cross-implementation interface onto the implementation's threading mechanism.
In demonstration of some intention, about the project:
Once understanding how SSC is to be implemented, I hope I will have an
opportunity to produce and to propose a patch onto McCLIM, for using SSC as
the threading interface in the kit.
It is my hope that in consequence iwth such a matter of effort, there may
become less duplication of code across Common Lisp systems, and that there
may become more familiarity, by develoeprs (myself included, to be sure)
familiarity with some general-purpose libraries.
I consider that some discussion about "shared functionality", in regards to
software systems design, might be apropos. I will have to make that as a
focus, for some explanation about the Tioga project.
I consider that I should denote, in the production of this project request: I
intend to add to the tioga project's codebase, a number of library systems
that I have been working on -- but to ensure that those systems are all
scrubbed-out, production-ready, "clean" before releasing the codebases out
from within my own Arch repository. (There had been a time of some months,
in which I was not able to obtain a direct connection to the internet, from
my home computer. During that time, I had begun to develop a couple of
library systems -- one 'commonlibrary', just some basic library routines,
condition types, etc; another, 'commonobject', with some extensions onto CLOS
and MOP; another, 'commonsystem', but that one is the most of a mess. The
last of those has been made as to include some extensions onto ASDF, but I
have been uneasy about how it has been approached. I can find some difficulty
at approaching the ASDF codebase -- ASDF::TRAVERSE, I cannot seem to do any
work with, and it not begin to behave in an unexpected manner, such that I
cannot determine the cause of, in any time I've so much as endeavored upon
it. I would like to consider MK:Defsystem as the driver system-definition
library to the Tioga project, but I am not sure of how it is going to be
developed. There is no public Defsystem 5, as yet. )
(I realize, some of those projects would be similar to existing projects --
such as CLOCC's cllib, and I recall that there is a sort of MOP-related
project at common-lisp.net. Of all code that is an extension on the Common
Lisp language, then of what libraries that I have written, I am the most
familiar with those. )
- To make a Debian Linux/GNU installation to be easier for the desktop user,
and for the hosts administrators, and for the networks administrators, each,
to use; to endeavor to develop Common Lisp systems, in so doing. Most of
those systems would probably be interfaed with CLIM.
- To address the distribution of Common LIisp software systems, in such that
may be made to include support about the hosts' primary packaging system,
but should not be made in disregard of the question, "What would be the most
convenient thing, for the developer?"
That might be addressed to an effect of something like a BSD 'ports' kind of
system on Debian -- the OS distributor taking the responsability to ensure
tha the code works, and works correctly with other code, before distributing
it.
- I suppose that some unit-testing would be a requisite part to it.
Not to add "just to add another to the stuck", but I may have to develop more
of what was a testing system called Rubrics; it could be hosted in the Tioga
project archives.
- To address ECMA TR/69, <Reference Model for Project Support Environments>,
onto a Common Lisp systems environment.
TR/69 is a 'standard' kind of publication. TR/69 is freely available via
http://www.ecma-international.org/publications/techreports/E-TR-069.htm
In some regards, TR/69 depends on ECMA's TR/55. (The latter of those is linked
from within the page at the previous URL).
As a part to the Tioga project, there may be produced some discussion of how
features of TR/55 are addressed -- addressed in implementation, whether or
not the implemnetation was intended as an implementation upon TR/55, but in
such that would be applicable onto TR/55 -- and are addressed, within the
Debian Linux complement of the free/open source softare systems environment.
---------
In regards to licensing: Any code produced of the Tioga project should be
licensed upon terms of the Franz LLGPL.
---------
In regards to sytems logisitcs:
- I would like to request the group name, 'tioga', for the project
As I have come to understand it: "Tioga" is a transliteration of a word from a
Native American dialect. I am not sure, offhand, what the original word would
mean; the transliterated form is applied in the name of a mountain pass, in
the Sierra Nevada mountains, in California.
(Tioga Pass opens from the east end of Yosemite Valley, opening onto the Great
Basin -- or opening onto the valley, if you're heading from the basin.
Considering how stark is the climate of the Great Basin, as well as how lush
is the vegetative quality of Yosemite Valley, Tioga Pass is quite a
transition area.)
- I would like to request that a 'trac' instance would be initialized for the
project.
- If it would matter, the project should not need a mailing list for
transmittal of logs about CVS checkins. TLA 'log' output may be enough;
there may need not be any further resources allocated for it, and I would not
ask to request any.
- In addition to the other (standard) project mailing lists I would like to
request if a 'tioga-admin' list may be initialized for the project.
I consider that the tioga-admin list may serve as a forum for discussion about
the development of the Tioga project web site. Certainly, the list would be
as like a forum, available in regards to any more of material pertaining
about the administration of the Tioga project.
- I do not have a shell account with common-lisp.net. If I would have the
opportunity to request a user name, I would request the user name 'schamp'
- attached to this email is an ASCII-armored export of the public compliment
to my public-projects GPG key. I have generated a revocation certificate for
it, and stored it for safe keeping)
- I consider that I should menton: That it is my intention that the Tioga
project will use TLA -- Tom Lord's Arch, an implementation of the GNU arch
SCCM architecture -- as the SCCM service for codebases of the Tioga project.
I consider that it would be your pergative, if there would be no CVS archives
that would be initialized for the Tioga project. I will state, simply, that
there should not need to be a CVS archive, for the Tioga project.
(I am aware that CVS and TLA systems may be made to interoperate. I have yet
to have found that it would be absolutely necessary that they would be made
to do as so. I am already familiar with CVS. I can use a CVS client, for
simple operations onto a CVS archive.)
-----
(NB: If your time would be short and if you would not want to read an
introduction about TLA, I would recommend, cordially, that you may skip over
the following section of this email.)
(I intend to produce an introduction about TLA, such that I consider may be
taken as to be in interst for the Common Lisp developer community. Given an
apperance of a reasonable cause, here, as for to produce a draft for the
intorudction, now -- and it would be in this email -- but I mean to address,
to you, here: Considerations that may be of relevance to the
hosts-administrator, in regards to GNU Arch)
I am aware that an Arch 'archive' (viz. repository) may be accessed by way of
the following means -- and that the burden for the access would reside,
almost entirely, at the client end:
* local filesystem
* SSH
* HTTP -- when without DAV support being available in the host (no problem)
then operating for read-only access (no problem)
In regards to a remote repository access, as onto a remote TLA archive, then
in regards to access onto common-lisp.net :
To a user who would be able to log in on the common-lisp.net SSH host (namely,
to a user who would have an account at common-lisp.net), to that user, SSH
access would be the most feasible.
(In sidebar: As for the Tioga codebase: SSH would be the access method used by
developers on the Tioga project.)
To a user who would not have an account to the SSH service at
common-lisp.net: The HTTP access method should serve to be enough.
As such, each user would make a 'mirror' of a selected archive 'category' (viz
a viz a CVS 'module') then mirroring any selected portions of the
upstream 'category' (across each selected category, branch, version, and
changeset), mirroring it into another archive, of the the user's own
determination -- e.g. so that it would be locally accessible, on the user's
primary desktop. When the user would not be able to access the repository by
way of SSH, then the user would need only an HTTP URL for the remote
archive -- and tla would have to be installed on the client that the user
would use for this -- so as to do so.
(Of course, when the user would access the upstream repository by way of HTTP,
and when the repository would be read-only to the user, then any changes that
the user would make onto the codebase of the repository, when submitted,
those changes would need to be submitted by way of email. TLA could be used
as to make this fairly easy, however -- the user could simply produce
a 'changeset' batch, then tar-gzip it up, and send)
The HTTP access method , it should not serve to occasion any burden on the
common-lisp.net web server. TLA operates as to package each changeset,
packaging the files of each one into an individual, gzipped tape archive (and
then, the archive file is checksummed). So, rather than a group of individual
files being accessed, it would be a single, compressed archive, accessed by
the TLA client, and accessed on each selected changeset.
(You know, I would like to recommend the following, to your consideration, and
I will have to take care of such, on the Tioga project's TLA archives -- will
have to look back over this email, after sending it: That some
robots-exclusion rules should be made, such that would be mapped onto the
HTTP-accessible compliments of the project's TLA archive directories -- as
such, into a robots.txt file in the host's document root, and so as to
prevent access that may be otherwise made to those directories, as by
web-spidering systems. There's not much sense they could probably make of
those gzipped archives, anyway.)
I'm sure you may be aware of the previous.
I'm sure that you may be aware, additionally, that TLA need not be installed
onto the system that would be running the file hosting for an archive, as
when that host would be remotely accessible. All of what a GNU Arch client
does, in regards to archive files, it is all done remotely, in access onto
the filesystem.
Client authentication, then, would be left to the host's operating system, and
to the service managing the mechanism for the archive access.
------
That text, in the section immediately previous, I will have to take it as it
being a first draft to an introductory tutorial about GNU Arch. I am glad to
have found this opportunity for to have begun upon the work.
I mean this as in a joke, the following, but with some humor, meant as to be
kind in tone: If this would appear as it being a long email for you to read,
then will you guess at how it has been, for my to have written this?
(I have thought that it has been worth the effort. Of course, I can only
expect if you would volunteer to read this.)
I think that the previous sections have been to the end of what I have
considered that I should state, as in this request for the initialization of
the Tioga project at common-lisp.net
Should you consder that this request will be met with approval: I would like
to thank you, then, for this opportunity to make the Tioga project available,
within it being provided in a comfortable, central location.
Formally,
Sean Champ
gimmal at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schamp.public-projects.public-key.asc
Type: application/pgp-keys
Size: 1702 bytes
Desc: ASCII-armored public GPG key, "Sean Champ (public projects) <gimmal at gmail.com>"
URL: <https://mailman.common-lisp.net/pipermail/admin/attachments/20060805/1df994b8/attachment.key>
More information about the Admin
mailing list