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@gmail.com