github discussions and email and project mission and ....

[Larry Masinter]

There's been a lot of discussion -- ever since we started -- about startup and accessibility of the environment and which directories are where, etc.

And some sense that perhaps if I were clearer about the mission of the project that we could adapt the system to meet that mission better if the initial default configuration would follow.

These topics in GitHub issues I labelled "config" and I probably missed some.

So the first thing to acknowledge is that this is a hard problem and there are a lot of things to consider. (more later).

The mission I have, in starting this project as a "thing" and setting up the web site and the mailing lists etc. was to make it so that the system would 'live". If only as an exhibit in a museum would be one possibility, but beyond that so much the better.  I don't know exactly what it will take. The museum community and digital preservation community and industry have ongoing conversations about the role of emulation in the preservation of software. 

I think if we can't attract a community who are able to and want to maintain the system over time, then we will have lost something. It might be OK enough for me to be able to demo Interlisp features to the Computer History Museum and then say "OK, we are done", and just archive the software we have, but that isn't enough for me and hardly motivating, for me.

Everyone coming to the project has different personal goals, but among them is the personal goal of having fun and being respected for their contributions.

Please consider that. The presentation that you all helped me with was an opportunity to speak to a community that be willing to pitch in.

One problem with using the new Discussion feature of GitHub (to avoid cluttering up the Issue list with philosophical project discussion) is that it seems like the feature's which allows email replies to email notification will post the reply as a separate "answer" to the top-level topic rather than a "reply". This leaves the conversation to seem even more disjointed and non-responsive to each other.  So please, if you want to reply to a discussion from GitHub notification email, do NOT reply-to the message but rather click on the "View it in GitHub" link and type your response in there.  Consider the fact that the discussion forum and issues and also the mail on this are public, and consider the impact it will have on the overall goal of keeping the system alive for another 30 years.

Right now we're all working with different backgrounds and expectations about what a "typical user" would want. I suspect we don't have a good idea of who a "typical user" might be or if there are several categories. 

Right now there are several entries to loading / installing / running medley and several on-ramps for people to start. The documentation consists of the web site, the readme's, some old scanned documents, the issue lists and GitHub discussions; Having lots of inconsistent sources of information can be worse than not having enough.

I hope this wasn't TL;DR matter.

Larry

-- 

https://LarryMasinter.net  https://interlisp.org

[Blake McBride]

Thank you, Larry, for your thoughtful input.  Certainly, there is a spectrum between making Medley work as it used to vs. making it a totally modern development environment.  Perhaps we each fall on different places within that spectrum.  Medley contains enough layers to make it somewhat daunting to someone not involved in its early years.  Therefore there is critical knowledge possessed by those who were involved in those early years.  Additionally, Interlisp represents an important milestone in the history of software engineering.  Those who were involved in that history are greatly respected and their contributions greatly appreciated.  Our modern software rests, in part, on your and others' shoulders.

In terms of where Medley goes from here, it is hard to tell.  As you state, it could become something people boot, say 'cool', and file away.  I might argue that some of the ideas that are embodied in Medley are worth considering for possible real use both now and in the future.  Of course, as it is increasingly ported and moved towards more modern use it becomes less and less of a museum piece.  In some sense, it loses its historic value and starts to become more of a modern value.  The code-base cannot fulfill both goals.

Perhaps a bifurcation of the project is in order.  The first project's goal would be to make the minimum changes necessary to be sure Medley operates reliably on modern machines but retains as much of the original project as possible in order to best retain the flavor and operation of the original project.  The second project's goal would be to take the first project and make whatever changes needed to make the system useful for real, modern development and native to modern environments.

To some extent, I see the current project as closer to the first project I describe with some ongoing but limited interest in the second project.  As a somewhat off the cuff list, perhaps:

Project 1 

Make the Medley VM build as warning free as possible

Ongoing Medley VM fixes

Add ability to generate an image from scratch

A number of X11 interface enhancements

Stop system from pegging the CPU

Documentation

Project 2

Native and cooperative integration with modern systems (my Directory proposal)

Change older path designation to a common format 

Move Common Lisp to ANSI CL (including PCL/CLOS)

Modern font usage

Update the UI to a modern motif

Documentation

Admittedly, these are some lofty goals.  Is there enough interest and resources to accomplish this?  I do not know.  Speaking for myself, I am totally pegged and work nearly seven days a week.  I certainly do not have the time.  On the other hand, just like a drug addict, I find myself uncontrollably drawn to Medley, so I probably will be involved and be able to devote some time.  I can't speak for others.

At this point, I feel a clean, agreeable bifurcation between the two efforts is best.  It makes sense in and of itself without other factors.  I have no plans at this point.  I welcome further discussion.

Thank you.

Blake McBride

[Blake McBride]

I think I missed the most global priorities when describing the two projects.  Perhaps a better list would be:

Project 1 

Make only changes needed to build and run the system reliably on modern systems but leave the original flavor and operation as original as possible

Make the Medley VM build as warning free as possible

Ongoing Medley VM fixes

Add ability to generate an image from scratch

A number of X11 interface enhancements

Stop system from pegging the CPU

Documentation

Project 2

Build on code from Project 1, move Medley towards a modern development system

Native and cooperative integration with modern systems (my Directory proposal)

Change older path designation to a common format 

Move Common Lisp to ANSI CL (including PCL/CLOS)

Modern font usage

Update the UI to a modern motif

Documentation

Blake McBride

[Larry Masinter]

Most open source projects and community efforts seem to operate on a Little Red Hen basis. 

I don't think it's useful to tell people what to do, since we're all volunteers. If someone asks, we can advise, or start issues (for well-defined problems) or discussions.

 In a (hopefully) small number of cases, it might be necessary to turn down a PR or suggestion because it interferes with someone else and their goals.

My suggestion for you include:  

work with Abe on updating the README files in Medley to be true and accurate,

work with Arun to help update the Medley user guide from the Envos archive.

produce PDF files from TEdit by means of print-to-postscript. and then review them

[Blake McBride]

Hi Larry,

I think I will do as you are implying.  Rather than trying to get a consensus and a team effort, I will make the directory changes myself.  We'll take things from there.

And to others - in spite of the frustration we may or may not have experienced over this issue, I want everyone to be clear that I deeply respect and appreciate everyone on the team.  I understand that, as individuals, we each have our own priorities and views.  I appreciate all of your help!

Thanks!

Blake